Forward-merge release/2.2 into develop - #368
Merged
Merged
Conversation
Closes #317. ## Summary The ghost-job reaper is meant to mark abandoned `RUNNING` jobs as `FAILURE` when a Dask worker crashes or is OOM-killed without raising a Python exception. Its detection query, `_find_stale_jobs`, was driven from `job_events` with an **`INNER JOIN job_info`**, so a job that entered `RUNNING` but had **not persisted any events yet** produced zero rows and was invisible to the reaper. That is exactly the failure the reaper's own docstring says it catches: the runner marks a job `RUNNING` before its first event is stored (and `BatchingEventStore` batches writes, widening the window). A worker crash/OOM in that pre-first-event window left the job stuck in `running` **forever** — status polling never reached a terminal state, and the job permanently counted against the active-job cap. ## Fix Drive the query from `job_info LEFT JOIN job_events` and use `COALESCE(MAX(je.created_at), ji.updated_at)` as the staleness clock: - Jobs **with** events keep the existing behavior (reaped when the last event is older than `GHOST_JOB_TIMEOUT_SECONDS`). - Jobs with **no** events fall back to `job_info.updated_at` (set when the job entered `RUNNING`), so a never-emitted ghost past the timeout is now reaped. - Added a guard for a missing `job_info` table (the query's new primary table). I verified in a real SQLite DB that both timestamp columns compare correctly — `job_info.updated_at` (`YYYY-MM-DD HH:MM:SS.ffffff`) and `job_events.created_at` (`YYYY-MM-DD HH:MM:SS`) are both text and order correctly against SQLite `datetime()`; in Postgres both are `timestamptz` and compare natively. ## Tests New `frontends/aiq_api/tests/test_ghost_reaper.py` runs against a real SQLite database so the SQL executes exactly as in production: - `test_zero_event_running_job_past_timeout_is_reaped` — the regression: a zero-event RUNNING ghost is now reaped. - `test_zero_event_running_job_within_timeout_is_not_reaped` — a freshly-started zero-event job is left alone. - `test_running_job_with_stale_last_event_is_reaped` / `..._recent_event_is_not_reaped` — existing event-based behavior preserved. - `test_non_running_job_is_never_reaped` — only RUNNING jobs are candidates. - `test_missing_tables_returns_empty` — fresh deployment, nothing to reap. - `test_mixed_fleet_reaps_only_ghosts` — realistic mix returns only the two genuine ghosts. The three zero-event assertions **fail against the old INNER JOIN and pass with the fix**. ## Test plan - [x] `pytest frontends/aiq_api/tests/test_ghost_reaper.py` — 7/7 pass - [x] Full `frontends/aiq_api/tests/` suite — 311 passed, no regressions - [x] `ruff check` + `ruff format --check` clean - [x] Verified timestamp-format comparability in SQLite and reasoned through Postgres ## Summary by CodeRabbit * **Bug Fixes** * Improved ghost-job cleanup so `RUNNING` jobs can be detected and reaped even when no job events have been persisted, using the latest heartbeat/lease timestamp fallback. * Hardened reaping to avoid race conditions by only transitioning jobs that are still `RUNNING`, and recording `GhostJobTimeout` when applicable. * Added a running-lease refresher to periodically extend leases for long-running workers. * Guarded `SUCCESS` persistence with a compare-and-set so it won’t overwrite terminal states. * **Tests** * Expanded SQLite-backed coverage for stale detection, zero-event reaping, atomic transitions, lease refresh threading, missing-table behavior, and success compare-and-set semantics. Authors: - Torkian (https://github.com/torkian) - Ajay Thorve (https://github.com/AjayThorve) Approvers: - Ajay Thorve (https://github.com/AjayThorve) URL: #318
Author
|
SUCCESS - forward-merge complete. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Forward-merge triggered by push to release/2.2 that creates a PR to keep develop up-to-date. If this PR is unable to be immediately merged due to conflicts, it will remain open for the team to manually merge. See forward-merger docs for more info.