[BUG] evaluate() returns errors without an ErrorCode or Reason on the UTF-8 and before-hook paths
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
Research direction
Start in client.go at the Client.evaluate early returns linked in the issue, then compare them with the nearby NOT_READY and FATAL short-circuits. Check the existing evaluation tests and specification references for the invalid UTF-8 and before-hook cases. Done means both paths return populated error details, with the UTF-8 hook behavior confirmed as intentional or covered separately.
Written by the indexing model from the issue text.
Description
Observed behavior
Two of Client.evaluate's early returns hand back an error with ErrorCode and Reason both empty.
Invalid UTF-8 flag key — returns a parse error, but nothing is written to evalDetails, and the error hooks don't run either:
Before-hook error — the error hooks do run, but the fields are still unset:
Contrast the NOT_READY and FATAL short-circuits just above, which set Reason, ErrorCode and ErrorMessage before returning.
Expected Behavior
Per 1.4.7, in cases of abnormal execution the evaluation details' error code field MUST contain an error code; 1.4.8 adds that the reason SHOULD indicate an error.
A before-hook error is unambiguously abnormal execution under 4.4.7, so 1.4.7 applies squarely there. The UTF-8 case is a parse failure before evaluation begins, and ParseErrorCode is the natural code.
The error hooks not running on the UTF-8 path looks like a separate defect on the same return — worth confirming whether that's deliberate.
Scope
Not the after-hook path, which has the same symptom (Reason stays STATIC, ErrorCode empty) but isn't decidable yet: whether an after-hook error counts as abnormal execution at all is under discussion in #566. That path should be revisited once that settles.
Related
- #542 — the
FlagMetadatagap on these same returns. Same lines, separate fix; keeping them in different PRs. - #537 / #538 — the same class of defect on the typed accessors' TYPE_MISMATCH paths.
- Dominant language
- Go
- Stars
- 251
- Forks
- 62
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 25
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-feature/go-sdk
-
[BUG] telemetry: feature_flag.context.id is emitted as an empty string when no targeting key is set Openbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
open-feature/go-sdk#563 ·
-
bug multi-provider Needs Triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
open-feature/go-sdk#560 ·
-
bug Needs Triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
open-feature/go-sdk#559 ·
-
bug Needs Triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
open-feature/go-sdk#558 ·
-
[BUG] FlagMetadata is handed out by reference, so hooks and applications can mutate provider state Openbug Needs Triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
open-feature/go-sdk#556 ·
All issues in open-feature/go-sdk
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100