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

[FR] Expose retry-attempt observability (hook/event) — retried 503s and per-attempt latency are invisible to callers

Aperta
#3,214 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 7 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
nodejs, typescript
Ambito
api, observability

Direzione di ricerca

Inizia dal comportamento di ritentativo indicato nel commento del codice api-request e analizza le opzioni di messaggistica o dell’app discusse nella richiesta, insieme alla issue correlata #1615. Il lavoro è completato quando i chiamanti possono osservare i tentativi di ritentativo, i dettagli dello stato o dell’errore, il tempo trascorso e se verrà effettuato un altro ritentativo, senza applicare patch agli internals di HTTP/2.

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

Descrizione

api: messaging
Is your feature request related to a problem?

The HTTP clients retry transient failures — per the code comment in api-request, "Retries up to 4 times on connection reset and timeout errors as well as 503 errors" — which is great, but the retry lifecycle is completely invisible to the caller. You observe only the final result and total elapsed time.

In production this matters a lot for FCM:

  • A sendEach() call that "took 15s" is indistinguishable from one that made three 5s attempts. Capacity planning, SLO attribution, and incident analysis need to tell these apart.
  • 503s that the SDK retries away never appear anywhere. During an FCM backend hiccup, our error rate looked flat while the wire was full of retried 503s — we only learned this after instrumenting below the SDK.
What we did as a workaround (and what it revealed)

We attached listeners at the HTTP/2 layer to record, per attempt, the :status header the SDK already receives, plus per-attempt request→response duration. Two things became visible immediately:

  1. Swallowed 503s during backend episodes (invisible at the SDK surface).
  2. Batches with ~15s total latency decomposed cleanly into 3 × ~5s attempts — i.e. the tail was retry behavior, not slow single requests.

We validated the accounting at scale: in a ~650k-message load run at ~2,000 rps, wire-level attempt counts reconciled exactly with SDK-level result counts (596,663 = 596,663).

Monkey-patching works but is version-fragile and clearly not the intended way.

Describe the solution you'd like

Any of these would solve it (in rough order of preference):

  1. An onRetryAttempt(info) callback / EventEmitter on the messaging or app options, with { attempt, statusCode?, errorCode?, elapsedMs, willRetry }.
  2. Attempt metadata attached to the final response/error (e.g. attempts: [{status, elapsedMs}, ...]).
  3. At minimum, a debug logging hook for retry decisions.
Describe alternatives you've considered
  • Runtime-patching the HTTP/2 request path to observe response headers (works, but couples us to SDK internals).
  • enableLegacyHttpTransport() + external proxy metrics (gives up HTTP/2).
Additional context

Related: #1615 (custom RetryConfig) — configuration and observability of the same mechanism. Verified against 12.7.0 and 14.1, on Node 16 and 24.

Lingua principale
TypeScript
Stelle
1.8k
Fork
420
Merge medio
5g 6h
PR unite (30g)
11

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 firebase/firebase-admin-node

Tutte le issue di firebase/firebase-admin-node

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.