lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(job-array-one-based-index): collision checks after registration (task 2.3)

Browse source 
handle_jobsubmit now registers the submission first and checks the job
table second; a hit is answered -EEXIST and released through the atomic
reply-and-release step. For array submissions, array_identity_exists()
does one read-locked scan of the 32768 tagged element keys of the
array's block (element 0 included for pre-upgrade arrays), covering
both the element range and the array identity; unmarked submissions
keep jobid_range_exists. An existing X|3 now blocks a new X|5.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-10-01 10:14:47 +00:00
parent 81bfaf1f50
commit fe5ddc9854
Signed by untrusted user: rshen
GPG key ID: 80533536B0EB651C
5 changed files with 278 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

7
src/controller/testsuite/test_commit_barrier_reply.c
View file

@ -1455,9 +1455,10 @@ static void test_jobsubmit_resubmit_before_resolution_rejected_no_dup_wal_entry(
/* bug-1419 residual: does the SAME dedup guard still hold AFTER the first
* attempt has fully resolved (committed, applied, replied, in-flight claim
* released via jobsubmit_async_ctx_release) -- not just DURING the
* still-unresolved window the test above proves. A live chaotic-soak run
* (2026-07-08) showed a genuine WAL-level jobid duplicate (two committed
* released together with the reply via inflight_reply_and_remove) -- not
* just DURING the still-unresolved window the test above proves. A live
* chaotic-soak run (2026-07-08) showed a genuine WAL-level jobid duplicate
* (two committed
* WAL_JOB_SUBMIT entries, same term, same primary) that neither known guard
* should have let through if the retry arrived strictly before OR strictly
* after resolution -- this test pins down whether the "after" window is as