open-feature / open-feature/go-sdk
[BUG] multiprovider: toProviderResolutionDetail maps FLAG_NOT_FOUND and TARGETING_KEY_MISSING to non-error reasons
- Dominant language
- Go
- Stars
- 249
- Forks
- 61
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 20
Description
## Observed behavior
`toProviderResolutionDetail` maps two error codes to reasons that assert success:
https://github.com/open-feature/go-sdk/blob/6b0824c6c7b9b69e40f26aedcc4406ad4d3a5cec/openfeature/multi/isolation.go#L125-L155
`FlagNotFoundCode` → `of.DefaultReason`, and `TargetingKeyMissingCode` → `of.TargetingMatchReason` — the latter reporting a *targeting match* as the reason for a **missing** targeting key. Every other code in the switch maps to `of.ErrorReason`.
Observed:
```
ErrorCode="FLAG_NOT_FOUND" -> Reason="DEFAULT"
ErrorCode="TARGETING_KEY_MISSING" -> Reason="TARGETING_MATCH"
ErrorCode="GENERAL" -> Reason="ERROR"
```
## Expected Behavior
Per [1.4.9](https://openfeature.dev/specification/sections/flag-evaluation#requirement-149), in cases of abnormal execution the `reason` field SHOULD indicate an error. Both should be `of.ErrorReason`.
## Scope / relationship to #543
Deliberately scoped narrowly. #543 covers the *missing* `ProviderNotReadyCode` / `ProviderFatalCode` cases in this same switch, where the zero-valued `resolutionErr` silently converts an error into a successful resolution. This issue is only about the two **mismapped reasons** on cases that *are* present.
They're adjacent enough to fix in one PR — happy to close this into #543 if maintainers prefer a single change.
Note this path only runs for providers wrapped by `hookIsolator`, i.e. any provider that has hooks or is registered via `WithProvider(..., hooks...)`.
## Steps to reproduce
Register a provider that returns `FLAG_NOT_FOUND` inside a `multi.Provider` with hooks attached (so `hookIsolator` wraps it), evaluate, and inspect `Reason` on the resolution detail — it reads `DEFAULT` rather than `ERROR`. Same shape with a provider returning `TARGETING_KEY_MISSING`, which reports `TARGETING_MATCH`.
Contributor guide
Research direction
Start in multi/isolation.go at the toProviderResolutionDetail switch linked in the issue, then trace how hookIsolator handles provider resolution errors. Reproduce the FLAG_NOT_FOUND and TARGETING_KEY_MISSING cases with a hooked provider and inspect the resolution detail; done means both abnormal cases report the error reason without changing the separate #543 scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 84/100