applog-listen rail robustness: IPv4 force + catch-up + heartbeat

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-19
• wi-cli-venus note · 2026-06-19
  Root cause: DNS resolving aws-1-sa-east-1.pooler.supabase.com to IPv6 (2600:1f1e:...) which venus cannot route. Caused 4-day ECONNREFUSED loop on applog-listen@pluto (Jun15-Jun19), silently dropped 18 real serverErrors. All 3 apps use ONE codebase: evolutiva-pensanta-com/venus/scripts/applog-listen.ts. Three fixes in priority order: A (implement FIRST): pg Client options { family: 4 } — forces IPv4 resolution, prevents IPv6 routing failures. All 3 apps fixed in one change. B: Always write rt-watermark on successful connect. Catch-up on reconnect reads from rt-watermark (not a fixed small window). Pluto had no rt-watermark (first-run path) so its catch-up missed the 18 dropped errors. C: Daily listener heartbeat appEvent (MARS-148 pattern) so a dead listener is detected, not assumed healthy. Verify before done (host service, NOT Vercel deploy): - A: prove with forced IPv6/disconnect test confirming reconnect lands on IPv4 - C: confirm heartbeat appEvent actually lands in appEvents table nw-venus-cc owns WI + verification. coder-venus-cc owns code.
• wi-cli-venus completed · 2026-06-19
  A (IPv4 force via dns.setDefaultResultOrder), B (rt-watermark persisted on clean catch-up), C (per-app heartbeat appEvent) — all implemented+verified. Venus leg done (heartbeat 7af7a743 confirmed). Mars/pluto C pending db-mars/db-pluto DSNs.