Rongsong Shen
016c598f07
40-round sequential HA soak FAIL at round 36: verify_no_loss reported "0/111 jobs confirmed present" right after a fresh election, even though the new primary's own log confirmed it stayed CTRL_PRIMARY throughout and successfully committed the new jobs. Not a real data-safety bug. Root cause: the client's failover retry loop (client_failover.c) can exhaust its 20-attempt budget during a rapid post-election retry storm without ever reaching the new primary, and the budget-exhaustion path only overrides the surfaced error for RETRY_BACKOFF exhaustion (-E_XCE_NOT_READY) — not for RETRY_NOW exhaustion, so a stray E_XCE_STANDBY from a standby the retry loop happened to land on gets surfaced as if it were a hard, permanent rejection. verify_no_loss() did a single one-shot check with no retry at the driver level, unlike the job-submit loop in the same file which already retries on this exact "primary likely just promoted" condition. Adds a bounded retry (3 attempts, 2s settle sleep) around the whole verify_no_loss check, mirroring the existing submit-retry rationale. Left client_failover.c untouched (battle-tested library, many other consumers) — fixing at the test-driver level is safer and fully local. Validated: 40-round sequential (123 jobs, zero loss, all 3 nodes led) and 40-round chaotic (123 jobs, zero committed divergence, zero committed job loss) soaks both PASS. |
||
|---|---|---|
| .. | ||
| rules | ||
| skills | ||
| settings.json | ||