From 48e01e26649130a6aae181f190d1abc7d31fe6fa Mon Sep 17 00:00:00 2001 From: Yonatan Dankner Date: Wed, 12 Aug 2026 15:45:51 +0200 Subject: [PATCH] Record the production verification of the CPU fixes Deployed to studyplanner-api from main (version e355b6c8) after PR #32. The backend tree on main is byte-identical to the branch the staging measurements were taken on, so production runs exactly what was tested. On production, on a verified-fresh isolate, period=all survived 120 rounds where it previously died after five. Twenty concurrent users completed 400/400 requests on a catalog session and 480/480 on a session that also includes /api/me/progress, favorites, semester-plans and completed-courses -- the authenticated half could only be exercised here, since staging cannot validate production-minted sessions. The health gate passes after the load with no isolate left wedged. That is the result that matters: this load used to leave permanently dead isolates behind, which is what users saw as everything failing for them while other users were fine. Co-Authored-By: Claude Opus 5 --- docs/load-test-2026-08.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/docs/load-test-2026-08.md b/docs/load-test-2026-08.md index 93d29c8..e80847d 100644 --- a/docs/load-test-2026-08.md +++ b/docs/load-test-2026-08.md @@ -224,6 +224,28 @@ request, and ~400 ms if that request is the first uncached catalog build. That i a per-isolate cost, not a per-user one, and it is the reason single-shot measurements mislead. +### Verified on production (2026-08-09) + +The fixes were merged (PR #32) and deployed to `studyplanner-api` from `main` +(version `e355b6c8`). The backend tree on `main` is byte-identical to the branch +the staging measurements were taken on, so production runs exactly what was +tested; the only other commits on `main` are frontend-only. + +| check | result | +| --- | --- | +| catalog correctness | 530138 B, 131 courses, byte-identical across repeats; `Ü` intact, no replacement chars | +| health gate before | 24/24 ok, 8 isolates | +| `period=all`, verified-fresh isolate (seq=6) | **survived 120 rounds** (previously died at 5) | +| 20 users x 20 requests, catalog session | **400/400 ok, 0/20 users affected** | +| 20 users x 24 requests, **including `/api/me/*`** | **480/480 ok, 0/20 users affected** | +| health gate after the load | **24/24 ok — no isolate left wedged** | + +The last row is the one that matters most: before the fix this load reliably left +permanently dead isolates behind, which is what users experienced as "everything +fails for me but works for everyone else". The authenticated half of the session +could only be exercised here, because staging cannot validate production-minted +sessions. + ### Contamination control (important) A dead isolate can outlive a deploy, and a live one carries whatever debt earlier