Skip to content

fix(bash_job_notify): do not treat JOB_NOT_FOUND as terminal failed - #23

Draft
cursor[bot] wants to merge 1 commit into
masterfrom
cursor/critical-bug-management-3193
Draft

fix(bash_job_notify): do not treat JOB_NOT_FOUND as terminal failed#23
cursor[bot] wants to merge 1 commit into
masterfrom
cursor/critical-bug-management-3193

Conversation

@cursor

@cursor cursor Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Bug and impact

When a remote worker restarts (upgrade/crash) or the daemon restarts, the in-memory job registry is lost while OS processes may still be running. The bash job notify watcher mapped JOB_NOT_FOUND (and local JobManager misses) to terminal status failed, injected a false completion notification, and removed the job from tracking.

This misleads the agent/user into believing a long-running background job failed when it may still be executing.

Root cause

_query_job_status() in bash_job_notify.py treated registry lookup failures as terminal failed status instead of an unknown/transient state.

Fix

Return None from _query_job_status() on JOB_NOT_FOUND or missing local handle so poll_terminal_jobs() keeps polling and does not emit a false failure notification.

Validation

  • Added tests for remote JOB_NOT_FOUND and local missing handle scenarios
  • pytest tests/test_bash_job_notify.py — 5 passed
Open in Web View Automation 

Worker restart or daemon restart can drop in-memory job registries while
OS processes still run. Keep polling instead of injecting a false failure
notification and removing tracking.

Co-authored-by: Yuxuan Liu <Osc-7@users.noreply.github.com>
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