Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Production request-time logs aren't reaching the deploy log collector

Aperta
  • Qualcosa non va?
#221 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
next.js, typescript
Ambito
observability

Direzione di ricerca

Start by reading lib/logger.ts and tracing how request-time log calls reach stdout in the production app process. Compare that path with the boot output captured by Railway, checking the process and buffering possibilities raised in the issue. Done means request-time application logs are visible in the production deploy log stream.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug help wanted

What's happening

The production app service's deploy log stream only ever shows container boot output (Next.js startup, migration notices, deprecation warnings). No request-time application logs show up after that — confirmed with railway logs --since 3h --filter "@level:warn" returning nothing, and the raw unfiltered stream staying at a fixed ~24 lines regardless of time range, even though HTTP network logs (a separate Railway feature) prove the app is actively handling requests minutes and hours later.

Why this matters

Any logger.warn / logger.error / logger.info call from inside a request handler is currently invisible in production. This blocked diagnosis of a separate bug (see the companion Telegram webhook issue) and generally means production incidents can't be debugged from logs right now — only from HTTP status codes and timing.

What's been ruled out

  • The logger itself writes structured JSON to process.stdout.write in production (lib/logger.ts) — same mechanism Next.js's own boot output uses, which does show up.
  • Not a search/filter UI quirk — confirmed via the Railway CLI directly (railway logs), not just the dashboard.

Open question

Why request-time stdout writes aren't reaching the same collector that captures the initial container boot output. Worth checking whether the process is forking/threading in a way that doesn't inherit the parent's stdout, or whether there's output buffering that never flushes under the actual request-serving code path.

Relevant code

  • lib/logger.ts
Lingua principale
TypeScript
Stelle
16
Fork
2
Merge medio
6h 51m
PR unite (30g)
151

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di answerLoops/answerLoops

Tutte le issue di answerLoops/answerLoops

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.