Rongsong Shen
d9aedc4b34
dispatch_a_job_()'s previously-unconditional job.allocs commit is now gated on xce_startjob_req() actually succeeding (rc >= 0). In that same successful branch, under a newly-acquired lock(j, RTTI_LOCK_WRITE) (a real pre-existing locking gap this call site had -- it took no lock on the job object itself before this), the job transitions to JOB_STAT_RUN, dispatch_fail_count resets to 0, and a WAL_JOB_DISPATCH fact is appended for durability. The failure path is otherwise unchanged -- classification and resolution of the six failure sites is tasks 3.2/3.3's job, not this one's. Adds an XCE_TESTING-only dispatch_a_job_test() wrapper (dispatch_a_job_() is static) and test_dispatch_commit.c, proving: state->RUN, allocs committed correctly, counter resets, and durability survives a real persist_recover() replay with no WAL_JOB_START present. Independently reviewed and approved. Two pre-existing, out-of-boundary findings surfaced and logged for later tasks: test_commit_barrier_reply.c's test_jobdispatch_receipt_ack_no_wal_append will need updating by task 5.4 (Req 5.3 anticipates this), and bug-1429's hang was reconfirmed a 3rd time (unrelated to this change). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cxa1PmqAB5PyXfJaNvj8TN |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||