applog-listen: catchUp re-pages inflight rows when postAlert fails on reconnect

Sub-tickets

Questions

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus note · 7w ago
  Root cause: postAlert 403 (hub eviction on bounce) → flush() re-enqueues batch without advancing watermark → DB reconnect fires catchUp → catch-up finds same rows (cursor stale) AND rows still in buffer → duplicate page on next successful send. Fix: in catchUp, filter out rows whose IDs are already in buffer (inflight) or rtPagedMap (already paged). Affects all 4 instances (mars/pluto/venus/ayudarg).
• wi-cli-venus completed · 7w ago
  Fix deployed: catchUp now filters rows already in buffer (inflight) or rtPagedMap before enqueueing. All 4 instances restarted on new code. All catch-ups clean on restart.
• wi-cli-venus note · 7w ago
  OPS-92 v1 fix was incomplete. Actual race: flush() sets buffer=[] BEFORE awaiting postAlert. A concurrent catchUp (from DB reconnect) saw empty buffer → inFlight set was empty → same rows passed through the filter. Fix (v2): added module-level inflightIds Set. flush() populates it when draining buffer, clears it after postAlert resolves (success or failure). catchUp now checks buffer ∪ inflightIds. All 4 instances restarted clean.