test(ffe): use canonical FFE fixtures - #8616
Conversation
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8616) and master. ✅ No regressions detected |
BenchmarksBenchmark execution time: 2026-08-14 04:26:42 Comparing candidate commit 30f66cb in PR branch Found 0 performance improvements and 3 performance regressions! Performance is the same for 69 metrics, 0 unstable metrics, 67 known flaky benchmarks, 59 flaky benchmarks without significant changes.
|
andrewlock
left a comment
There was a problem hiding this comment.
Please don't use git submodules. We'd rather have a job that periodically pulls in the data from other projects if that's the desired approach.
Alternatively, we can use the system-tests approach which clones the other repo and runs tests against it in CI, if that's a possibility
This reverts commit 2077a24.
834879c to
280cbd9
Compare
## Motivation Use the shared FFE fixture corpus. This prevents copied Go fixtures from drifting from other SDKs. The same migration is merged in [Java](DataDog/dd-trace-java#11355) and [libdatadog](DataDog/libdatadog#1979). Related migrations are open for [Python](DataDog/dd-trace-py#19390), [JavaScript](DataDog/dd-trace-js#8441), [Ruby](DataDog/dd-trace-rb#5742), and [.NET](DataDog/dd-trace-dotnet#8616). ## Changes and Decisions - Add `DataDog/ffe-system-test-data` as an OpenFeature test submodule. - Read all canonical configuration and evaluation cases from the submodule. - Parse and validate flags independently so one invalid flag does not reject valid neighbors. - Assert canonical values and reasons, including temporal defaults and missing-flag errors. - Initialize submodules in Go test workflows and configure weekly Dependabot updates. Co-authored-by: leo.romanovsky <leo.romanovsky@datadoghq.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d4765eaabb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
andrewlock
left a comment
There was a problem hiding this comment.
LGTM in general, with some suggestions.
Thanks for following through with this approach! 🙂
|
Thanks for the review @andrewlock . After taking another look, I agreed that representing an invalid flag as a nullable Flag value was undesirable: it encoded parsing state through null and exposed an awkward I replaced it with an explicit three-state lookup:
|
Motivation
Use the shared FFE fixture corpus so the .NET evaluator is checked against the same behavior as the other tracer implementations. This reduces fixture drift and gives us a repeatable way to expose and correct evaluator bugs when new canonical cases are added.
The same fixture corpus is used by Java, libdatadog, Go, Python, JavaScript, and Ruby.
Changes
DataDog/ffe-system-test-data.SOURCE.md.FLAG_NOT_FOUNDfor missing flags and classify temporal, static, and split allocations.Fixture update flow
When we add or change shared evaluator behavior, I imagine the flow working like this:
DataDog/ffe-system-test-dataand review the expected behavior there.This keeps new behavior explicit and reviewable: fixture changes land in the canonical repository first, and each tracer then gets a visible compatibility PR rather than silently changing at build time.
Decisions
DataDog/ffe-system-test-dataremains the canonical source of shared evaluator behavior.