Source identity
| Field | Recorded value |
|---|---|
| Source type | GitHub source |
| Original record | Janady13/missionmatch / docs/evidence/phase2/stress/gate-b-results.txt |
| Date | Not specified in source |
| Repository | Janady13/missionmatch |
| Revision | 720d47fae476b0d38477ae4401697d372b1ea2bc |
| Branch | feature/opportunity-to-outcome |
| Path or archive member | docs/evidence/phase2/stress/gate-b-results.txt |
| Original SHA-256 | 143a0beab0104070df1a4f7e9435fcfc90983b4924575aa02dc6932be2128e8c |
| Git blob SHA | b04746f25147034c8f5937880fd6b5146109382c |
| Reading-copy SHA-256 | 143a0beab0104070df1a4f7e9435fcfc90983b4924575aa02dc6932be2128e8c |
Recovered source transcript
Download complete source text ↓61 lines · 3.1 KB
GATE B, STRESS. Phase 2, 28 July 2026, re run at phase close so the whole bundle
is one measurement of one commit rather than a scrapbook of runs taken at
different times. Instrument: tools/verify/stress. Target: missionmatch_staging on
M4:5432, 2,766 organizations. The tool REFUSES to run against a database named
missionmatch, because it creates and destroys rows.
EVERY PROFILE'S POSITIVE CONTROL RAN FIRST AND FAILED AS REQUIRED.
RACE CONTROL. The first planted defect simply removed FOR UPDATE and the run
still produced one winner, because the timing did not happen to interleave.
That proved the harness ran, not that the assertion can catch a second winner,
and a control that only sometimes manifests is itself an instrument that
passes by doing nothing. The defect was made DETERMINISTIC by removing the
already claimed guard, so every racer claims and the exactly one winner
assertion is put under real pressure. It elects 8 of 8 every time:
race n=8 winners=8 (want exactly 1)
positive control OK: the planted defect was DETECTED
LOAD CONTROL, an unmeetable p95 target of 1ns:
load samples=30156 rps=1005 p95=10.524ms p99=12.466ms errors=0 target=1ns
positive control OK: the planted defect was DETECTED
SOAK CONTROL, the same:
soak samples=61742 rps=1029 p95=10.136ms p99=12.214ms errors=0 target=1ns
positive control OK: the planted defect was DETECTED
COUNTED RUNS
CONCURRENCY, the protocol asks for 8 AND 32 on every lock guarded transition:
race n=8 winners=1 PASSED
race n=32 winners=1 PASSED
LOAD, 30 seconds, 8 workers:
samples=30583 rps=1019 p95=10.402ms p99=12.646ms errors=0
targets p95<300ms p99<800ms zero errors: ALL MET
SOAK, 60 seconds at the same shape:
samples=61329 rps=1022 p95=10.273ms p99=12.526ms errors=0
Latency is flat between the load and soak runs, p95 10.402 to 10.273,
which is the stability the soak profile exists to observe.
Measured p95 is roughly 29 times inside the 300ms target at about a thousand
reads per second sustained for a minute, with no errors.
A SECOND HARNESS DEFECT BELONGS IN THE RECORD. The pool was smaller than the
racer count, so the profile deadlocked and looked exactly like the contention bug
it exists to find. MaxConns is now deliberately larger than any racer count used
here, and the reason is written at the line that sets it.
SCOPE LIMIT, STATED RATHER THAN GLOSSED. The load and soak profiles measure the
DATABASE path, not authenticated HTTP. Driving the hot routes with real sessions
per role needs seeded fixture accounts for every role, which is Gate C fixture
work that does not exist yet for Phases 3 onward. Quoting a database read as an
end to end request latency would inflate the number every time it is repeated
later. Measuring what can honestly be measured today, and saying so, is better
than reporting an HTTP number produced by a harness that logged in as nobody.
ALSO PROVEN, at Gate A but concurrency shaped: eight racing promotions of one
requirement draft while an ingest loop rewrote the underlying notice 29 times
produced exactly ONE requirement with a named reviewer.