Repository navigation
fix: honor priority at effective admission capacity - #59
Conversation
Reproduce a declared head losing the sole free slot while three original reads run, and at a live capacity below the configured width. Preserve the control that a queue fitting all free slots starts without a priority read.
Apply the existing declared and fallback ordering after the live capacity and pool width are known. Subtract running admissions before deciding whether waiting candidates compete for slots, and do the same before the existing refill failure barrier. Preserve complete snapshot ownership in one-shot mode and avoid a priority command when no new slot can be taken.
|
CI run 39519718517 is now successful on the unchanged candidate 0d13516 (tree37febc496f002d96b35b719247b97de59471c833): Python3.11,3.12,3.13, proofs and container all PASS in attempt2. The first attempt remains a retained failure: the original OwnedSlots.test_new_priority_is_read_before_an_unstarted_older_head asserted h3 != h99. A bounded paired investigation reproduced that exact assertion on unchanged baseline daemon b2e96af615ebb975497437d0f049d304cf7cee44 with original checker14eae77be0c36544d72ffae365dcd5b2616bcb8f. On local Python3.12.14, default scheduling passed60/60 on each source; a1-microsecond interpreter switch interval produced59/60baselinePASS and60/60candidatePASS. The baseline failure occurred at iteration39 with calls h1,h2,h3,h99, and99 still merged. This demonstrates the existing dispatch-entry ordering race; it does not measure equal failure rates or reproduce the exact Python3.13 environment. Production _submit, _timed_read, _read_admission and _owned_candidates remain AST-identical. The candidate source, fixtures and all original assertions were kept frozen. One established failed-job retry was requested after that evidence; no source or test adjustment was made to obtain the subsequent CI result. |
Problem
Candidate ordering used the configured admission width before live capacity and running admissions reduced the available slots. With four configured slots, three reads still running, and two waiting candidates, the priority command was never consulted; the ordinary head took the only free slot. A live capacity of one with two waiting candidates had the same failure.
Change
Move the existing ordering and round trimming after the capacity and executor-width observations, and compare the waiting queue with the slots actually free. Apply the same ordering before the existing refill failure barrier. The declared ranks, waiting-age and retry tie-breakers, eligibility rules, unknown-capacity refusal, original futures, and final ownership selector remain unchanged. One-shot mode continues to own its complete snapshot. A queue that fits starts without another priority command; no command is needed when no slot can be taken.
Validation
The test-only commit
6751e39d5d26d02544800658971296d3b7aa299awas pushed first. Its unchanged-runtime run produced two failures selecting head 41 instead of declared head 42, with the queue-fits control passing. The production-only fix is0d13516d5751b14c30e9c162b859d5946df8199c, tree37febc496f002d96b35b719247b97de59471c833.The original
make testpassed all 455 tests in 21.982 seconds, including the original end-to-end demonstration. All 179 source files were identical before and after that execution; original test files were preserved. Raw log SHA256:1b015d7fe6d2e10c450578fefe18b38362b17b472ac03560223664b36f337627.An independent source/receipt review confirmed that the existing rank/trim body and all other daemon methods are unchanged; the tick adds the two ordering calls. The original proof and container CI remain required:
lakeanddockerare unavailable in the local checking environment. This PR does not establish a deployed throughput improvement.This continues the existing owner branch after #58 merged; there is no other open delivery for that branch.