forked from lei.chen/myxce
jobid_range_exists() only checks c->jobmgr, but task 3.1 deliberately defers job construction until after commit -- so a submission that is durably WAL-appended and awaiting its commit outcome is invisible to that check. A client-side retry (XCECLI_FAILOVER_CALL resending the same jobid after a transport error or failover mid-flight) sails past the guard and appends a second, non-identical WAL_JOB_SUBMIT entry for the same jobid -- confirmed via waldump on a live chaotic-soak node (duplicate submits, same jobid, differing subtime/CRC) -- which can trip persist_recover()'s post-replay apply-correctness check into a genuine APPLY_DIVERGENT verdict. Adds a process-lifetime in-flight-jobid-range registry in job.c that handle_jobsubmit atomically check-and-claims immediately after the existing jobid_range_exists check, releasing from jobsubmit_async_ctx_release (the single choke point already shared by the commit-continuation, apply-complete, and OOM early-out paths). A resubmit for a still-in-flight jobid now gets -EEXIST with no second WAL append. Adds a matching XCE_TESTING reset seam (declared in cluster.h) so a test that deliberately leaves a submission's commit continuation unresolved through teardown doesn't leak its jobid range into a later test reusing the same range -- commit_engine_fini frees pending continuations without invoking their callback. Regression test added to test_commit_barrier_reply.c (RED->GREEN confirmed). Full 78-group controller_unit_test sweep: 782 tests, 0 failures. This fixes only the WAL duplicate-submit mechanism (layer 1 of bug-1419). The deeper PreVote-freshness/apply-divergence liveness deadlock (layer 2 -- no recovery path when the only fresh-enough node is apply-divergent-fenced) remains open and needs its own design discussion; buglog.json updated accordingly. |
||
|---|---|---|
| .. | ||
| cluster.h | ||
| commit.h | ||
| slowlane.h | ||
| worker.h | ||