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

flagd: align retry defaults with spec, fix retry `maxAttempts`, emit STALE on stream errors

Aperta
#408 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
grpc, python
Ambito
api, backend

Direzione di ricerca

Inizia da config.py:31-32 e confronta la politica di retry in resolvers/grpc.py:105 e resolvers/process/connector/grpc_watcher.py:82 con la specifica referenziata. Leggi _state_change_callback in grpc_watcher.py:178, _handle_rpc_error a :273 e _wait_before_reconnect a :318 per ricostruire la gestione degli errori dello stream. Il lavoro è completato quando i valori predefiniti e maxAttempts corrispondono alla specifica e le disconnessioni dello stream emettono STALE seguito da ERROR dopo il periodo di tolleranza del retry.

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

Descrizione

We must implement open-feature/flagd#2027, which proposes changing the spec defaults so the stream-reconnect backoff can't leave us disconnected longer than the stale grace period.

  • config.py:31 DEFAULT_RETRY_BACKOFF_MAX: 12000 -> 5000
  • config.py:32 DEFAULT_RETRY_GRACE_PERIOD_SECONDS: 5 -> 10

Both resolvers also set maxAttempts to 3 (resolvers/grpc.py:105, resolvers/process/connector/grpc_watcher.py:82), but the spec's retry policy specifies 4 (the initial attempt plus retries at 1s, 2s, 4s); should be 3 -> 4. Harmless to fix now since nothing clamps at a 5000 cap.

Separately, we don't emit STALE on sync-stream errors. _state_change_callback (grpc_watcher.py:178) only emits STALE when the gRPC channel enters TRANSIENT_FAILURE, and a stream-level error doesn't change channel state, so _handle_rpc_error (:273) logs at debug and we silently wait retry_backoff_max_ms in _wait_before_reconnect (:318) before re-establishing. For that whole window we're disconnected while still reporting READY.

Measured on 0.5.2, in-process resolver, flagd latest:

Scenario Result
stream_deadline_ms=3000, flagd untouched stream dies at 3.01s, reconnects at 15.01s, zero lifecycle events
default deadline, flagd killed for 1.3s zero lifecycle events

With the default stream_deadline_ms of 600000 that's a silent 12s disconnect every ~10 minutes. Java, Go and JS all emit STALE on stream error here, and per the spec a stream disconnect should emit STALE, then ERROR after retryGracePeriod.

Lingua principale
Python
Stelle
27
Fork
33
Merge medio
5h
PR unite (30g)
10

Guida per i contributori

Apri la guida per i contributori

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 open-feature/python-sdk-contrib

Tutte le issue di open-feature/python-sdk-contrib

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.