You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Four findings on PR #972; addressing all.
1. `consecutiveFailures` semantic mismatch (jetstream-ingestor.ts +
records-do.ts). Docstring claimed "0 means the most recent attempt
produced events", but the run loop unconditionally incremented after
each connectAndConsume return. So the counter was always ≥ 1 after
any disconnect, including ones that successfully streamed events.
Fix: increment only when no progress was made; reset to 0 (without
increment) when progress was. Also added a regression test that
asserts the counter stays 0 across three connect-disconnect cycles
that all produced events.
2. `/_admin/start` returned the DO's status body (cursor + failure
count). Even an idempotent admin endpoint shouldn't leak operational
data to anonymous callers. Fix: route now fires the DO fetch via
`ctx.waitUntil` and returns a fixed 204 — caller learns nothing
about whether the DO was already running, just woke up, or is
mid-startup. The DO's fetch handler still returns the status body
(used internally by the cron liveness pump, which doesn't proxy it
either).
3. Unhandled rejection in `wrapAtcuteSubscription.close()`. `void
inner?.return?.()` suppressed the value but did NOT catch
rejections. If the inner iterator's cleanup ever rejects (today it
shouldn't, but a future EventIterator change could), workerd would
surface an unhandled-promise warning. Fix: chain `.catch(() => {})`.
Tests: 14 (was 13; added counter-semantics regression). 0 lint, 0
typecheck.
0 commit comments