Fleet server-side error/404 capture: client-side-only logging leaves 3 blind spots (non-JS clients, auth-redirect-before-render, API/server 404s) — push-tier errors can be silently dropped upstream of the applog rail

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-21
• wi-cli-venus note · 2026-06-21
  CONFIRMED FLEET-WIDE (code-confirmed mars+pluto+venus, ayudarg same green-field): 404 capture is CLIENT-SIDE only — not-found.tsx → client useEffect → POST /api/log-404 → appEvents WARN. 3 blind spots where errors are NEVER captured: (1) non-JS clients (curl/bots) - no JS = no row; (2) auth-gated route hit unauth - redirect to /login before not-found renders; (3) API/server-side 404s bypass not-found.tsx. SEVERITY: ratified push protocol bs-mqn2ze006f7 puts 404-on-own-route in PUSH/error tier, but those 404s can land in blind spots -> push-tier errors silently dropped UPSTREAM of the applog rail. Rail itself is healthy (MSG-82); this is capture completeness. GOAL: server-side capture, complete regardless of client, honoring ratified tier (404-on-own-route=push; bot-probe no-referer/random=digest-only, carve-out preserved). IMPL CONSTRAINTS: (a) not-found.tsx is a Server Component -> can logEvent server-side, closes #1; BUT unmatched pathname isn't cleanly server-exposed in Next (reason it's client today) - solve via middleware-set req header carrying path. (b) API/server 404s (#3) need a catch-all route handler or shared helper. (c) auth-redirect (#2) is a redirect not a true 404 - decide whether to capture at the auth-gate as a separate signal. (d) GOTCHA pluto WI#486: server action POSTs to unmatched path -> 404s before body runs; that's why it moved to route handler - don't repeat. (e) venus: instrumentation.onRequestError catches thrown 500s only (notFound() doesn't throw); middleware excludes /api/*. (f) TEMPLATE: pluto has proven per-page server-side capture (mi-cursada/[id], practicas/[id]) emitting server-side event before notFound(). LEGS (file under parent EVO-12, each app PM owns): mars (pm-mars-cc), pluto (pm-pluto-cc), venus (pm-venus-cc), ayudarg green-field (pm-ayudarg-cc - best time to do it right). HELD pending Elazar priority call.
• wi-cli-venus statusChanged · 2026-06-21
  GREENLIT per ratified brainstorm bs-mqn8g0rhso5 (4/4, Elazar in-room; EVO-12 = fleet-restore item 1, greenlight routed to pm-llmmsgsrv). Legs released to app PMs. Canonical: server-side capture (client-independent), 404-on-own-route→error/push, bot-probe→digest carve-out, pluto per-page template. Per-app close proof = genuine wrong-URL-on-own-route round-trip (DM+email both land).
• wi-cli-venus note · 2026-06-21
  CANONICAL CLARIFICATION (coder-ayudarg-cc catch, generalpm-evolutiva endorsed): the 404 close-proof MUST come from the SERVER-SIDE 404-CAPTURE path, NOT instrumentation.ts. notFound() renders the not-found boundary WITHOUT throwing, so onRequestError never sees a 404. EVO-12 email = TWO paths, ONE dormant flag-gated sender: (1) instrumentation.ts onRequestError -> direct in-process SMTP on real 500s (DB-down class, per bs-mqn8ogqjpze LEG-1); (2) server-side 404-capture -> email when tier===error (own-route 404s). Adding the verified send-as lights up both. DO NOT wire the 404 email into instrumentation.ts.
• wi-cli-venus note · 2026-06-21
  PREDICATE CORRECTION (audit-venus catch, 2026-06-21): the 2-signal guard (RSC soft-nav AND manifest-match) is UNSOUND - it downgrades a genuine data-miss notFound() on a valid dynamic route (e.g. /practicas/[badId] via RSC nav) to WARN, breaking the data-miss-stays-ERROR invariant. CANONICAL FLEET PREDICATE is now 3-signal: downgrade error->warn ONLY when ALL of (1) RSC soft-nav headers present, (2) path matches a valid CURRENT route via build manifest, (3) served build-id/deploymentId != current build-id (stale build). Signal (3) is the discriminator - data-miss on the current build has matching build-ids so stays ERROR; true deploy-skew (stale build) downgrades. Supersedes the 2-signal 'final' note. venus 3-signal version is the reference.
• wi-cli-venus note · 2026-06-21
  PREDICATE CORRECTION v2 (mars-audit catch, 2026-06-21): signal-3 is PLAN-CONDITIONAL, not a uniform build-id mandate. The client-expected build-id reaches the server ONLY via the Vercel Skew-Protection header (Pro+); on Hobby it is absent so no server-side build-id compare is possible. Circular: where the header exists (Pro+) Skew Protection already routes stale clients to their old deployment so the stale-404 mostly never fires (guard moot); where the guard is load-bearing (Hobby) the header is absent. CORRECTED CANONICAL: Pro+ app = Skew Protection handles stale-404 at source, in-app build-id mismatch is belt-and-braces; Hobby app = signal-3 = build-recency <=10min timer (canonical-correct for Hobby, NOT a degraded fallback) but LOSSY: a real data-miss 404 within <=10min of a deploy is downgraded to warn for that window (bounded, post-deploy only). The <=10min Hobby lossiness is the Q3 go/no-go cost for Elazar. Supersedes the build-id-mandate note.