infra/scripts/t3-dispatch
Viktor Barzin 9b19caff47
All checks were successful
ci/woodpecker/push/default Pipeline was successful
ci/woodpecker/push/build-cli Pipeline was successful
t3: connection logging across the path for drop attribution
Viktor asked to add connection logs (Traefik/Cloudflare) to catch the
real-path t3 WS drops: a direct-to-t3-serve browser ran 40 min clean
while real tunnel sessions cycle every 15-35s, so the drop originates
above t3-serve and we need to see which layer cuts the socket.

Traefik (/ws duration) and cloudflared (WS close events) already ship to
Loki; the gap was the devvm side. This adds:

- t3-dispatch logs every /ws open/close with dur_ms + cause:
  downstream_closed (client/CF/Traefik hung up = last-mile/network),
  upstream_closed (t3-serve closed/reset), or graceful. Graceful closes
  previously left no trace (default ReverseProxy only logs on error), so a
  watchdog-driven reconnect was invisible. Helpers unit-tested.
- devvm-promtail.{yaml,service}: ships devvm journald (t3-dispatch +
  t3-serve@<user>) to cluster Loki as job=devvm-journal, mirroring the
  pve/rpi-sofia shippers. devvm was never in Loki (standalone VM).

Joined in Loki the three layers attribute any future drop to a segment
with no repro needed. Runbook + service-catalog updated.
2026-06-11 13:48:10 +00:00
..
go.mod t3: connection logging across the path for drop attribution 2026-06-11 13:48:10 +00:00
go.sum t3: differential drop-attribution probe + devvm metrics 2026-06-10 21:11:29 +00:00
main.go t3: connection logging across the path for drop attribution 2026-06-11 13:48:10 +00:00
main_test.go t3: connection logging across the path for drop attribution 2026-06-11 13:48:10 +00:00
probe.go t3: differential drop-attribution probe + devvm metrics 2026-06-10 21:11:29 +00:00