The first multi-core A/B was void: ~100% non-2xx on every row, so 'sustained
rps' was error-path throughput, not store work -- the spin patch's park/wake
path was never exercised. The harness reported it cheerfully anyway.
- spin_ab_urus.sh: per-run output now computes non-2xx vs approx total and
prints 'VOID: N% non-2xx' instead of a meaningless rps when >2% error.
- loadgen/_diag_status.lua: single-thread wrk script that tallies exact status
codes (response() + done()) and names the likely cause (401=auth not
reaching server / 404=store not pre-populated / 503=store actor down).
The aggregate 'Non-2xx' count can't distinguish these; this can.
Root cause still open: locally the store survives heavy keep-alive load (no
panic), prepop populates, auth+happy-path serve 200s -- so the storm isn't
reproducible in this 1-core sandbox. s3 at ~100% (not ~80%) rules out a plain
404 storm and points at auth or store-call erroring on every request; needs
the diag run on the real box to confirm.
sandbox-agent
926aba4344