open-feature / open-feature/go-sdk

[BUG] multiprovider: toProviderResolutionDetail maps FLAG_NOT_FOUND and TARGETING_KEY_MISSING to non-error reasons

Open Beginner friendly
#560 0 comments 0 reactions 0 assignees View on GitHub
bug multi-provider Needs Triage
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.