Skip to content

Conversation

antonije
Copy link

These changes fix the following issues:

  • long-running jobs were being blocked until the first one completes
  • jobs having double states (being in "QUEUE" and "IN_PROCESS") before actually being accepted
  • stop recreating the jobs_queue and setting initial maxsize

NOTE: I have added longer sleep in the run_jobs method to suit my needs, but feel free to edit those.

…progress

Previously, jobs were marked as "in progress" in `get_jobs()` immediately after being fetched from the server, before they were actually scheduled by `run_jobs()`. This caused jobs to appear both in the queue and in progress simultaneously, which inflated `current_occupancy()` and blocked new jobs from starting until earlier ones had finished.

The fix moves the `job_progress.add(job)` call into `run_jobs()`, right after the job is dequeued and scheduled as a task. This ensures that:

- Jobs are only marked "in progress" once they actually start running.
- Queue and progress metrics no longer overlap.
- Concurrency limits are enforced correctly (e.g. with concurrency=4, two jobs now run in parallel instead of sequentially).

As a result, jobs are dispatched immediately when capacity is available, and status logging reflects the real state of the worker.
- add a timeout of 100 milliseconds that doesn't block the code and accepts new jobs
@Yhlong00 Yhlong00 requested a review from deanq September 12, 2025 20:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant