Independent technical demonstration, not customer work.
A small Node.js/TypeScript order service acknowledged every order with HTTP 202 before securing processing capacity. Under heavier burst load, many accepted orders remained pending even after the service became idle. The scoped repair made those failures explicit, without increasing capacity or changing the acquisition deadline.
The failure
The service processed orders through a resource pool with capacity eight. An order could wait up to one second for a slot. If acquisition failed, the original error handler did not record a terminal failure.
In the matched pre-repair test at 2,000 orders, an average of 484.2 orders were processed and 1,515.8 remained pending across five repetitions. All orders had been accepted; none was reported failed. The pending state was observed at the idle end of each run. Indefinite persistence was inferred from the code, rather than measured through a long-delay recheck.
Diagnosis and scoped change
Source inspection identified the discarded-error path. Earlier runtime confirmation tests strongly supported the acquire-timeout explanation: extending the deadline removed pending stranding at the tested volumes, while doubling it increased the number processed. Those earlier comparisons also differed in platform and client seeds, so they did not isolate the timeout’s contribution completely.
The repair changed one server file. On acquisition or processing rejection, a nonterminal order is marked failed, receives a resolution timestamp and increments the failure counter. Existing handle-release logic, HTTP 202 admission and the original one-second timeout remain in place.
The intended contract is terminal accounting: an accepted order becomes processed or failed. Explicit failure under overload is an allowed outcome; a successful response to admission does not guarantee successful processing.
Measured before and after
Fresh comparisons ran on the same host/runtime with identical client seeds and settings: volumes 100, 150, 500, 1,000 and 2,000; five repetitions each; concurrency eight; pool capacity eight; acquire timeout 1,000 ms. Server jitter remained unseeded.
At 2,000 orders, the means were:
| Final state | Original | Repaired |
|---|---|---|
| Processed | 484.2 | 488.2 |
| Pending | 1,515.8 | 0 |
| Failed | 0 | 1,511.8 |
All 25 repaired runs reached quiescence and satisfied accepted = processed + failed, with zero pending, processing or not-found orders. Server counts matched the independent client ledger. There were no recorded HTTP errors, client timeouts or duplicate accepted IDs. The pool drained and active processing stayed within capacity.
The change improved failure visibility and accounting. It did not establish a throughput improvement; small differences in processed counts are subject to scheduling and unseeded jitter.
Independent review
Kiro implemented the patch and produced the before/after evidence. Codex reviewed the actual diff, reconciled all 50 raw load runs, checked source/patch consistency and verified the original 37-file evidence inventory. Codex also independently built the repaired source and executed an additional HTTP regression confirming that timed-out contenders did not release a holder’s pool slot and that normal processing still completed.
The independent load review used recorded artifacts; Codex did not rerun the full load sweep. The processing-rejection path was reviewed in code but not independently fault-injected.
What this demonstration establishes
The owner accepted the scoped repair after review. Under the tested conditions, accepted orders no longer remained silently pending at quiescence: overloaded work became visible, counted failures.
This is not a fully blind diagnostic benchmark. The investigation is classified PARTIALLY CONTAMINATED because the investigator encountered a revealing source comment and later owner-review narratives. Its interpretation cannot be presented as independent of those materials.
The service remains in-memory. The demonstration does not establish durable delivery across restart, retries, successful completion of every order, production readiness or behavior across all workloads and configurations. The onset-locator test remains deferred. Historical total engagement time and remaining budget are unknown, so no total-duration or cost-efficiency claim is made.