writeonce/docs/examples/porch/middleware
shoney.arickathil aa13b2125f refactor(porch-store): re-scope porch 1 to the limiter, revert idempotency
- idempotency built, reviewed, then reverted WHOLE to the tag
  archive/porch-idempotency. Not a design failure: it passed its gates.
  It provokes a C-runtime SIGSEGV in wo_arena_alloc/wo_str_new under
  concurrent call()-parked callers
- the evidence for that attribution: over ten gate runs every failure
  was an idempotency leg and none was the limiter's, which drives the
  same pool through the same call/park machinery. The begin arm has 5x
  the allocation sites inside receive and moves a whole Req plus a
  Handler through the mailbox
- before the split the suite reported 0 to 6 failures run to run; after
  it, five consecutive runs at 56 checks, 0 failures
- PoolMsg loses digest/req/handler, and NullHandler/dummy_req/fresh_req
  go with them — every rate-limit count used to allocate a throwaway
  Req it never read
- IdempotencyKey is KEPT and commented: the schema is settled and the
  digest-as-column decision cost a review round to get right
- the limiter's saturation 503 has no leg of its own now (§19 drove
  Idempotent). Stated in the README rather than papered over — a
  deterministic leg needs a slow actor, and only the reverted arm was
- new: porch 9 (idempotency, on hold) and language 41 (the arena crash,
  with the reproduction harness and the evidence that localises it)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 79e6da4465133dc555e913c960d544ef1c7bedd8)
2026-09-15 01:25:00 +02:00
..
keypool.wo refactor(porch-store): re-scope porch 1 to the limiter, revert idempotency 2026-09-15 01:25:00 +02:00
limiter.wo fix(porch-store): log a genuine pool_count trap, not just 503 silently 2026-09-15 01:15:30 +02:00
store.wo refactor(porch-store): re-scope porch 1 to the limiter, revert idempotency 2026-09-15 01:25:00 +02:00