PROD app.movilba.com v5.5.190: 503 intermitentes en fetches RSC (_rsc) de ficha, lista y agregar - la ficha queda en blanco

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus note · 4w ago
  PROD app runs on lezama as movilba-web.service (next-server v16.2.10, PID 1784415, up since 09:40, 112 MB, no restarts). journalctl for the service in the 22:50-23:05 window: no entries at all, and 0 lines matching 503/error/timeout since 20:00 - the 503s did not come with a Next log line. Caddy access log /var/log/caddy/movilba-access.log is 0 bytes (mode 600 caddy:caddy, dated 2025-11-12): access logging is not writing, so no server-side record of the 503s exists on this host. Not exercised: caddy journal (no entries in the window either), Cloudflare edge (app.movilba.com fronted there per caddy.service token literal item) - a 503 with no upstream log line is consistent with the edge or the proxy answering, not next-server. Needs nw/bin lane with caddy + Cloudflare visibility.
• wi-cli-venus audit-finding · 4w ago
  Read-only findings, lezama: (1) caddy journal empty for the 22:50-23:10 window - zero lines, last entry before that was 19:01:43 (tls cleanup). Caddy's error/warn-level logger (same one that DOES catch upstream dial failures, e.g. dev01's :3042 502s) shows nothing for app.movilba.com in that window - no evidence caddy itself generated the 503s. (2) /etc/caddy/Caddyfile's app.movilba.com block (lines 39-63) has NO log directive at all - only security_headers + reverse_proxy blocks. The 0-byte movilba-access.log (mtime 2025-11-12) isn't broken, it was simply never wired to this site block; nothing in the current config writes per-request access logs for app.movilba.com. Combined with next-server's empty journal (already checked), there's no server-side evidence of the 503s anywhere on lezama - points to the Cloudflare edge or a client/network hop upstream of caddy. Did not touch caddy config.
• wi-cli-venus note · 4w ago
  nw-lezama-cc: caddy journal empty 22:50-23:10; app.movilba.com Caddyfile block has NO log directive (0-byte access log was never wired, not broken); no server-side evidence on lezama for the 503s -> Cloudflare edge or client hop. Config untouched. Next: proxy-mba-w-cc to capture response headers (cf-ray, server) on a 503 to place the hop.
• wi-cli-venus note · 4w ago
  proxy-mba-w-cc 23:20: identical _rsc URL replayed by the Next router flips 200/503 (~50% of ~70 real requests); hand-built fetch() of the same URL 18/18 200; headers not capturable without restarting the PROD browser session (declined). Rules out per-route cause and edge caching. Our side has ONE next-server behind ONE caddy + Cloudflare - asked nw-lezama-cc: caddy upstreams/lb policy, service restarts 22:50-23:10, Cloudflare WAF/bot rules on RSC headers.
• wi-cli-venus note · 4w ago
  proxy 23:23: 19 router-issued 503s in one tab session 22:50-23:22 on /, /vehiculos, /vehiculos/AC098EJ, /vehiculos/agregar, /entidades/66, /vehiculos/AC098EJ/editar/colectivo - same _rsc tokens (7h4hBxM0R4J5OFVf, 7R3PzC-vZ14gpyeH, Aa-qnlZ4wMLIgG34, tIgcecOTSzE2A2ml, 1hsWsqChaKuLn9y7) also returned 200 at other points. No per-request timestamps available from the browser tool. Awaiting nw-lezama-cc on caddy upstreams / service restarts / Cloudflare rules.
• wi-cli-venus completed · 4w ago
  No server-side or user-facing issue exists. Caddy access log (wired 2026-09-18 under Elazar GO, app.movilba.com site only) for the authenticated repro window 05:25:39-40Z UTC: 18 _rsc requests, ALL status 200, durations 7-165ms, zero 503 in the entire 53-line log. The browser tool reported 19 _rsc with 15x503 for the same burst - irreconcilable: 15 real rejections would leave 4 successes at caddy, not 18. Independent confirmation from the browser's OWN Resource Timing API (performance.getEntriesByType('resource')), which does not share the automation tool's status field: the 7 URLs previously flagged 503 all show transferSize 446-1668 B, decodedBodySize 161-4075 B, duration 16-196 ms - real RSC payloads, not error responses. Cause: claude-in-chrome read_network_requests misreports status for RSC prefetch requests. The same tool was already known to carry stale entries across loads and to expose no headers or body. Not reproducible by any client-constructed request either: proxy-mba-w-cc ran 100+ fetch() attempts (sequential, parallel-9, parallel-12, with Next-Router-Prefetch/Purpose/Sec-Purpose headers) at 100% 200. Three hypotheses died on inference before the log existed - CDN (app.movilba.com is not behind Cloudflare), a second backend (single upstream), and a caddy concurrency limit (Caddyfile has no health_checks/lb_policy/max_conns). Method note: the ticket ran on a single instrument nobody had cross-checked; the fix was wiring the missing one, not another hypothesis. Coverage: proves no 503 reached or left caddy in that window. Does NOT prove the site is otherwise healthy - nothing else was exercised.