myxce/.wolf/bugs/bug-1907.md
Rongsong Shen ac40eebb5c
docs(buglog): bug-1907 reproduction wording
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-02 02:14:11 +00:00

59 lines
3.8 KiB
Markdown

---
id: "bug-1907"
status: "fixed"
status_updated: "2026-10-02"
status_note: ""
component: "controller"
severity: "wrong-result"
timestamp: "2026-10-01T15:49:05Z"
last_seen: "2026-10-01T15:49:05Z"
occurrences: 1
files: ["src/controller/src/job.c", "src/harness/test.c"]
tags: ["harness", "job-control", "not-found", "job-array"]
related: ["bug-1896"]
fix_commits: ["47551fb2"]
---
# bug-1907: harness setpend and jobrun cannot report not-found: the controller acks status 0 first
## Description
**Observed:**
Found by code reading, no failing run captured. Both controller handlers reply before looking the job up:
```
src/controller/job.c:2246 handle_jobdispatch: init_reply_by_req(); reply.status = 0; xce_reply(...) /* then the work */
src/controller/job.c:3869 do_set_preason: init_reply_by_req(); reply.status = 0; xce_reply(...) /* then the work */
```
So harness `jobrun -j <id>` and `setpend -j <id>` succeed for a job (or array element) that does not exist.
**Expected:** like the other single-job commands, `jobrun`/`setpend` on an unknown job ID report "not found" (job-array-one-based-index Requirements 4.7 and 5.13).
**Impact:** wrong result: a test script that targets a wrong element (e.g. `$jobid[0]` on a new array) passes silently instead of failing.
**Found by:** review (job-array-one-based-index task 4.3 implementation notes and feature validation, 2026-10-01)
## Environment
- OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
- libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
- Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
- Build: asan (src/build.jai)
- Code: scheduler-framework @ efff6b65-dirty
- Deployment: any (controller request handling)
## Reproduction
1. Start a controller (xce-deploy-ha) and run `xce_test` against it.
2. `jobrun -j 0-0-1-5` (an ID that was never submitted) and `setpend -j 0-0-1-5 -p 1`: both report success (before 47551fb2).
3. Compare `jobkill -j 0-0-1-5`, which reports not found. (`jobrun` is a client-context command; `setpend` is in the scheduler context.)
- Frequency: deterministic (1/1 live, 2026-10-01)
- Evidence: /home/claude/tmp/bug-1907-red.out
## Root cause
`handle_jobdispatch` (`src/controller/job.c:2246`) and `do_set_preason` (`job.c:3869`) send their reply with status 0 before touching the job; a missing job is only logged afterwards (`set_preason` PERROR, `dispatch_a_job_`). The early acknowledgement is deliberate: the scheduler sends these requests in batches and its publish/retry/redelivery logic (`scheduler.c`, `test_scheduler_decision_publish_retry.c`, `test_scheduler_decision_redelivery.c`) depends on it. The harness commands `jobrun` and `setpend` used the same requests and so reported success for any job ID.
## Fix
Harness only; the controller/scheduler protocol is unchanged. New `job_exists_or_report()` in `src/harness/test.c` looks the job up with the same interruptible `xcecli_jobinfo` call `jobinfo` uses and judges the result with `cmdutil_job_lookup_report()`; `cmd_jobrun` and `cmd_setpend` call it before sending their request and return -ENOENT with "<cmd>: job <arg> not found" (plus the `<array-id>[k]` hint for a bare identity).
## Verification
- Test: live harness script against a 3-node controller deploy (no unit seam: the commands need a controller). RED before the fix: `jobrun -j 0-0-1-5` printed nothing and `setpend -j 0-0-1-5 -p 1` printed `ok`, script exit 0 (/home/claude/tmp/bug-1907-red.out). GREEN after: both print `job 0-0-1-5 not found` + hint and exit 1; `jobrun -j $jobid[3]` on a missing element reports it not found; `setpend`/`jobrun` on the real `$jobid` still succeed (exit 0)
- Suites: harness meson suite 7/7 OK (asan, src/build.jai)
- Live: the GREEN run above (xce-deploy-ha, controllers only, 2026-10-01)
## References
- Related: none