flagd: align retry defaults with spec, fix retry `maxAttempts`, emit STALE on stream errors
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 68/100
調査の方向性
config.py:31-32 から始め、resolvers/grpc.py:105 と resolvers/process/connector/grpc_watcher.py:82 の retry ポリシーを参照されている仕様と比較します。_state_change_callback（grpc_watcher.py:178）、_handle_rpc_error（:273）、_wait_before_reconnect（:318）を読み、ストリームエラーの処理を追跡します。仕様にデフォルト値と maxAttempts が一致し、ストリーム切断時に retry の猶予期間後、STALE に続いて ERROR が発行されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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:31DEFAULT_RETRY_BACKOFF_MAX: 12000 -> 5000config.py:32DEFAULT_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.
- 主要言語
- Python
- スター
- 27
- フォーク
- 33
- 平均マージ
- 5時間
- マージ済み PR（30日）
- 10
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
open-feature/python-sdk-contrib のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
open-feature/python-sdk-contrib#417 · コメント 1 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
open-feature/python-sdk-contrib の issue をすべて見る
似ている issue
-
agent-ready documentation needs-triage
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
-
documentation
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" オープン
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
-
instance instance add
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
searxng/searx-instances#939 · コメント 1 件 ·
-
area-deployment area-integrations triage:bot-seen
難易度 2/5 半日 初心者へのやさしさ 86/100