[flagd] The two resolvers disagree on numeric coercion: in-process returns TYPE_MISMATCH, RPC returns 0
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Issue で説明されている get_integer_details のケースを使って、provider の in-process および RPC resolver パスを比較します。まず、既存の conformance-suite の結果と既知の逸脱のエントリを確認します。flagd coercion ADR と resolver の動作を flagd-testbed:v3.8.0 と照合します。意図されたコントラクトが決定され、2 つのトランスポートの結果が一致しているか、残る逸脱が明示的に文書化されていれば完了です。
索引モデルが issue の本文から書いたものです。
説明
The two resolvers of this provider answer the same question differently, and I would like to know which one is intended before assuming either is wrong.
What I measured
float-flag resolves to 0.5. Requesting it through get_integer_details with a code default of 1:
| resolver | result |
|---|---|
| in-process | 1 — the code default, with TYPE_MISMATCH |
| RPC | 0 — no error code at all |
Both against flagd-testbed:v3.8.0, same flag, same call, same run. The widening direction agrees:
integer-flag (10) requested as a float returns 10.0 from both.
So in-process rejects a lossy narrowing and RPC performs it silently.
Why I am asking rather than filing it as a bug
The rule this would be measured against is flagd's own, not OpenFeature's. OpenFeature has a
single numeric type — number is "a numeric value of unspecified type or size" — and no numbered
requirement says what a provider must do when a value does not fit the accessor it was asked
through; that is an open question of the provider contract
(open-feature/spec#430). flagd accepted a coercion
ADR for itself — coerce when lossless, TYPE_MISMATCH when information would be lost — tracked in
open-feature/flagd#1996.
Against that rule the in-process resolver is already correct and the RPC one is not. But that is
flagd's rule to interpret, which is why this is a question.
What does not depend on which answer is right: two transports of one provider disagreeing is a
vendor-neutrality problem on its own terms. An application that switches resolver= — a
configuration change, not a code change — gets a different value and a different error code for the
same flag and the same call. That is the property the conformance suite exists to check, occurring
inside a single provider.
Calibration from the other languages
Worth knowing before deciding, because it suggests where the fix belongs:
- The Java and Go flagd providers narrow
0.5to0with no error code in both resolvers
— consistent with each other, both matching this repository's RPC behaviour. - This provider is the only one of the four whose two resolvers differ, and the only one where any
resolver implements the ADR's lossy half.
So the in-process path here appears to be ahead of the other implementations rather than behind them.
Questions
- Is the in-process behaviour the intended one, with RPC yet to catch up?
- If so, is the gap in this provider's RPC path, or is it that the evaluation happens server-side
there and the answer has to come from flagd itself? - Is there a reason the two paths should be permitted to differ that I am missing?
Context
Found while building the cross-language provider conformance suite proposed in
open-feature/spec#417. Both resolvers now declare
the @numeric-coercion capability and the results record the difference, with a known-deviation
entry against the RPC suite only — the in-process suite does not carry one, because it does not have
the defect. Nothing is blocked either way.
- 主要言語
- Python
- スター
- 27
- フォーク
- 33
- 平均マージ
- 1日 11時間
- マージ済み PR（30日）
- 20
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
open-feature/python-sdk-contrib のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
open-feature/python-sdk-contrib#439 ·
メンテナーはふだん 1 日以内に返信
-
UnleashProvider.track has the wrong signature: client.track raises TypeError instead of no-op対応中かも @aepfli が 28 日前に担当しました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
open-feature/python-sdk-contrib#433 ·
メンテナーはふだん 1 日以内に返信
-
Restore the .gitmodules branch pins so Renovate tracks flagd submodule versions again対応中かも @aepfli が 32 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
open-feature/python-sdk-contrib#421 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
open-feature/python-sdk-contrib#417 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
fix(flagd): use custom channel credentials in RPC resolver対応中かも @tuhinkanti が 11 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 35/100
open-feature/python-sdk-contrib#454 ·
メンテナーはふだん 1 日以内に返信
open-feature/python-sdk-contrib の issue をすべて見る
似ている issue
-
Questions crashes on a real SQuAD2 no-answer prediction対応中かも @HuaTNA が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
GST is read as Gulf Standard Time (UTC+4) instead of Guam Standard Time (UTC+10)対応中かも @yang00333 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
DOI-USGS/dataretrieval-python#454 ·
メンテナーはふだん 4 日以内に返信
-
area:core-platform effort:S priority:P3 status:in-review type:test
難易度 2/5 1時間未満 初心者へのやさしさ 80/100
randomparity/kdive#3246 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Requantification library converts m/z to mass with the hydrogen-atom mass instead of the proton massオープンbug
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
nf-core/metaboigniter#130 ·
メンテナーはふだん 1 日以内に返信
-
netbox status: needs owner type: documentation
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
netbox-community/netbox#23412 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信