--- id: "bug-1737" status: "fixed" status_updated: "2026-09-24" status_note: "" component: "lib" severity: "unknown" timestamp: "2026-08-30T22:05:00Z" last_seen: "2026-09-19T09:00:00Z" occurrences: 1 files: ["src/controller/sched.c (sched_job_exit_fun", "renamed sched_job_finish_fun)", "src/scheduler/src/handler.c (sched_handle_notify's NotifyData_data_schedExitJob case)", "src/schema/controller.capnp (schedExitJob field)", "src/include/typemap.h (xce_notify_data_t's sched_exit_job union member)", "src/lib/helper.c (xce_notify_data_ptr)"] tags: ["scheduler", "controller", "wal", "notify", "capnp", "job-state", "exit-code", "done-vs-exit", "confirmed-live"] related: ["bug-1731", "bug-1734", "bug-1738"] legacy: true --- # bug-1737: User-reported (live 3-node HA cluster + worker, 50-element array job `sleep 100 && hostname`… ## Description User-reported (live 3-node HA cluster + worker, 50-element array job `sleep 100 && hostname`, xce_scheduler -i -s vs controller joblist): job 0-8-1788143749-0[38] shows EXIT in the scheduler's replay (`info jobs`) but DONE in the controller's joblist -- confirmed a REAL state divergence (JOB_STAT_EXIT=0x04 and JOB_STAT_DONE=0x08 are genuinely different bits, src/include/xce/types.h), not cosmetic. ## Environment _Not recorded (migrated from buglog.json)._ ## Reproduction _Not recorded (migrated from buglog.json)._ ## Root cause CONFIRMED via direct code reading (both static and, indirectly, live -- the fixed behavior was verified against a real captured replay; the pre-fix defect itself was not separately re-reproduced live in this session since fixing it was done in the same pass). HOOK_DETAIL_JOB_EXIT fires for EVERY job finish, both success and failure -- job.c's record_job_finish_fact()/apply_job_finish_transition() decide DONE (exit_code==0) vs EXIT (exit_code!=0) BEFORE firing this exact hook detail either way (mirrors persist.c's own WAL_JOB_FINISH -> HOOK_DETAIL_JOB_EXIT mapping, `case HOOK_DETAIL_JOB_EXIT: return WAL_JOB_FINISH;`). sched.c's sched_job_exit_fun() (the HOOK_DETAIL_JOB_EXIT subscriber that notifies the scheduler) receives xce_jobfinish_t* info (which HAS an exit_code field) but never read it -- it unconditionally sent a bare jobid via NotifyData_data_schedExitJob (controller.capnp's schedExitJob was a plain UInt64, no exit_code at all on the wire). scheduler/src/handler.c's sched_handle_notify() then unconditionally mapped ANY schedExitJob to JOB_STAT_EXIT, with no way to ever land on JOB_STAT_DONE via this live path. Under STABLE connectivity this was normally self-correcting: the SAME WAL apply also fires HOOK_DETAIL_JOB_UPDATE moments later (persist.c:4854-4855, immediately after the HOOK_DETAIL_JOB_EXIT fire, same lock scope), which carries the job's REAL, already-final job->job.state via schedUpdateJob -> XCE_CORE_EVENT_JOB_UPDATE's `job->state = updated->state;` (core_events.c), overwriting the wrongly-forced EXIT with the correct DONE within the same notify batch. But this is TWO SEPARATE notify() calls, not atomic -- if the scheduler's connection blipped between them (the same reconnect-flakiness bug-1731/bug-1734 already documented live under this exact 50-element-array load), the correcting schedUpdateJob could be dropped (c->sched.ep NULL at fire time) while the earlier, wrong schedExitJob(EXIT) had already landed -- leaving the scheduler permanently stuck at EXIT for a job the controller correctly recorded as DONE. This exactly explains why only ONE array element (out of 50) showed the divergence: only that job's particular pair of notifies happened to straddle a reconnect gap. ## Fix FIXED (2026-08-30). Reused the EXISTING JobFinishInfo wire shape (jobid + code) apiserver_job_exit_fun() (apiserver.c) already sends for this identical hook, rather than inventing a new capnp struct: controller.capnp's schedExitJob field changed from `UInt64` to `JobFinishInfo`; typemap.h's xce_notify_data_t.sched_exit_job union member changed from `uint64_t` to `xce_jobfinish_t*`; sched.c's sched_job_exit_fun() (renamed sched_job_finish_fun() for accuracy -- it covers both DONE and EXIT outcomes, not just EXIT) now sends `.sched_exit_job = info` (the whole struct, mirroring apiserver_job_exit_fun's `.finishinfo = info` pattern) instead of `info->jobid`; scheduler/src/handler.c's sched_handle_notify() now reads finish->exit_code and mirrors job.c's own decision exactly: exit_code==0 -> JOB_STAT_DONE, else -> JOB_STAT_EXIT, instead of unconditionally assuming EXIT. helper.c's xce_notify_data_ptr() updated to match the new pointer type (dropped a now-redundant void* cast). TDD: added test_handle_notify_job_exit_maps_exit_code_to_done_or_exit (test_handlers.c) -- exit_code==0 -> DONE, exit_code!=0 -> EXIT, NULL payload -> -EINVAL (no crash). Full lib+controller+scheduler+worker build and test suite (both a dedicated full build via xce-build.sh and an incremental rebuild+retest after further edits): 61/61 Ok for controller+scheduler (66/67 overall including lib, the 1 failure a pre-existing unrelated ASAN-leak fixture bug already logged separately, not caused by this diff), xceadmin 288/288. Live-verified: deployed a fresh 3-node HA cluster + worker with the fixed binaries, submitted a 51-job workload (50-element array + 1 standalone job, all exiting 0), let everything run to completion -- the scheduler's replay showed DONE for every single job, matching the controller's joblist exactly, with zero EXIT/DONE divergence. ## Verification _Not recorded (migrated from buglog.json)._ ## References - Related: bug-1731, bug-1734, bug-1738