Repository navigation
runtime: consider a deferred-dispatch admission bound (goroutine per accepted event) #44
Description
Under DispatchDeferred, every accepted routed event spawns a detached tail goroutine that retains the event until handler completion or DetachTimeout. There is no admission bound: a flood of unique routed events grows goroutines/memory linearly until DetachTimeout catches up. This applies to every strategy (drop/queue handlers on distinct threads today; concurrent slot-waiters and burst/debounce waiters after #38 — #38 already bounded debounce by exiting superseded waiters promptly).
Raised by the Codex security review on #38 (thread: #38 (comment)). A pre-spawn admission cap must decide what happens to acknowledged events beyond the cap (silent discard = a new drop policy + new configuration), so it should be designed once for deferred dispatch as a whole — likely alongside ADR 0002/0012 — rather than per strategy.
Options sketched: a bounded admission semaphore ahead of startDetachedTail with an explicit overflow policy (drop-with-observation), reusing webhook-layer backpressure (HTTP 429 before ack), or a documented operator contract that admission control belongs in front of the webhook.
Generated with mux • Model: anthropic:claude-fable-5 • Thinking: xhigh
Activity
ThomasK33 commentedon Aug 27, 2026
Extending scope per the round-2 Codex security review on #38 (thread: #38 (comment)): the admission-bound design should explicitly cover
ConcurrencyBurstbatch growth (per-scope event/byte caps with an explicit overflow policy) alongside the per-event detached tails — batch members retain event payload + handler closure until their window drains even though they hold no goroutine.ThomasK33 commentedon Aug 27, 2026
Triage: accepted — design-first, sequenced after #38. Verified:
DispatchDeferredadmits a goroutine per accepted event with no admission bound; a unique-event flood scales goroutines/memory linearly untilDetachTimeout. Because the fix defines backpressure semantics across all adapters (reject-with-429 vs drop-with-observation vs bounded admission inRuntimeOptions), this gets an ADR proposal first, not a direct patch. Holding until PR #38 (concurrency strategies) lands so the design covers the full strategy surface, includingConcurrencyBurstbatch growth.Generated with
mux• Model:anthropic:claude-fable-5• Thinking:xhighrefactor(runtime): stage burst and preemption behind the coordination…
feat(runtime): ADR 0012 concurrency — debounce, concurrent, lockScope…
docs(adr): ADR 0015 — deferred-dispatch admission bound; cross-instan…
ThomasK33 commentedon Aug 27, 2026
Design accepted — ADR 0015 merged (984d094). This issue is now the implementation contract; relabeled
ready-for-agent.Implement per ADR 0015:
MaxDetachedper-instance cap; reject-with-signal before ack and before dedupe-mark (ErrAdmissionRejected); shape-aware adapter mappings (retry-inducing for platform-redelivered shapes, truthful busy signal for direct invocations); optionalMaxDetachedPerTenantkeyed on(adapter, tenant)per ADR 0006; observability hooks; constructor validation.Hardening tests must cover the mechanism findings from the #54 review history: slot release on errored preludes, slot-until-goroutine-return, shutdown admission close, negative/empty-tenant validation, counter GC.
Also in scope (lands with implementation): CONTEXT.md glossary entry (Admission Bound), ADR 0012 status note reflecting the supersessions, flip ADR 0015 to Accepted.
Generated with
mux• Model:anthropic:claude-fable-5• Thinking:xhigh