Rongsong Shen
16d90319db
Adds test_rpc_failure_bound_resets_after_intervening_success to test_dispatch_fail_retry.c, proving Requirement 4.3's literal claim end-to-end through the real dispatch_a_job_test() entry point: a fail, then a real success, then another fail resets the consecutive-failure counter so the second failure is evaluated as failure #1, not #2. The first draft of this test also asserted job.state/job.allocs revert to PEND/NULL on that post-success failure -- this genuinely fails against current code (none of dispatch_a_job_()'s four retryable branches revert state/allocs when failing from an already-RUN job, since they were only ever designed for a job whose every attempt starts from PEND). A debug investigation, independently re-verified even more exhaustively during review (full trace of every pendJobs-reinsertion and controller-side state-mutation site), confirmed this scenario is unreachable via any real caller today -- the scheduler's picker permanently removes a job from its PEND pool the instant it dispatches it, and nothing already-implemented ever re-adds a RUN job to it. Only the not-yet-implemented scheduler-preemption spec could someday create that path. Logged as bug-1631, deliberately deferred rather than fixed now (no reachable caller to regression-test against); the two over-reaching assertions were trimmed, keeping only the counter proof Requirement 4.3 actually asks for. Independently reviewed and approved. Scenarios 1 (retryable -> PEND-eligible) and 2 (bound exceeded -> EXIT) were already fully covered by tasks 2.2's and 3.3's existing tests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cxa1PmqAB5PyXfJaNvj8TN |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||