Skip to content

test(openfeature): use canonical FFE fixtures - #4753

Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 9 commits into
mainfrom
leo.romanovsky/ffe-canonical-fixtures-20260512
Jul 31, 2026
Merged

test(openfeature): use canonical FFE fixtures#4753
gh-worker-dd-mergequeue-cf854d[bot] merged 9 commits into
mainfrom
leo.romanovsky/ffe-canonical-fixtures-20260512

Conversation

@leoromanovsky

@leoromanovsky leoromanovsky commented May 12, 2026

Copy link
Copy Markdown
Contributor

Motivation

Use the shared FFE fixture corpus. This prevents copied Go fixtures from drifting from other SDKs.

The same migration is merged in Java and libdatadog. Related migrations are open for Python, JavaScript, Ruby, and .NET.

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.

@codecov

codecov Bot commented May 12, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.46%. Comparing base (8839f29) to head (9de1759).

Additional details and impacted files

see 280 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@pr-commenter

pr-commenter Bot commented May 12, 2026

Copy link
Copy Markdown

Benchmarks

Benchmark execution time: 2026-07-31 22:23:17

Comparing candidate commit 4868373 in PR branch leo.romanovsky/ffe-canonical-fixtures-20260512 with baseline commit 9873869 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 326 metrics, 0 unstable metrics, 1 flaky benchmarks without significant changes.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Known flaky benchmarks

These benchmarks are marked as flaky and will not trigger a failure. Modify FLAKY_BENCHMARKS_REGEX to control which benchmarks are marked as flaky.

Known flaky benchmarks without significant changes:

  • scenario:BenchmarkOTLPTraceWriterFlush

@datadog-prod-us1-6

datadog-prod-us1-6 Bot commented May 12, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 96.08%
Overall Coverage: 63.02% (+11.59%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 4868373 | Docs | Datadog PR Page | Give us feedback!

@leoromanovsky leoromanovsky changed the title Use canonical FFE fixtures test(openfeature): use canonical FFE fixtures May 12, 2026
@leoromanovsky
leoromanovsky marked this pull request as ready for review May 13, 2026 03:15
@leoromanovsky
leoromanovsky requested review from a team as code owners May 13, 2026 03:15
@leoromanovsky
leoromanovsky requested review from dd-oleksii and typotter and removed request for a team May 13, 2026 03:15

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9de1759c0e

ℹ️ 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".

Comment thread openfeature/evaluator_test.go
@kakkoyun

Copy link
Copy Markdown
Member

@leoromanovsky Shall we revive this?

@leoromanovsky

Copy link
Copy Markdown
Contributor Author

@leoromanovsky Shall we revive this?

@kakkoyun That sounds great; pushed latest main and resolved conflicts.

@leoromanovsky
leoromanovsky requested a review from kakkoyun July 28, 2026 13:56

@kakkoyun kakkoyun left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@sameerank sameerank left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also a recommendation to add submodules: recursive to fetch submodules of this workflow might fail because it runs scripts/ci_test_core.sh, which tests ./... including openfeature.

Comment thread openfeature/remoteconfig.go
@leoromanovsky
leoromanovsky requested a review from sameerank July 31, 2026 21:51

@sameerank sameerank left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌

@gh-worker-dd-mergequeue-cf854d
gh-worker-dd-mergequeue-cf854d Bot merged commit 6d96ff5 into main Jul 31, 2026
191 checks passed
@gh-worker-dd-mergequeue-cf854d
gh-worker-dd-mergequeue-cf854d Bot deleted the leo.romanovsky/ffe-canonical-fixtures-20260512 branch July 31, 2026 22:56
leoromanovsky added a commit to DataDog/dd-trace-dotnet that referenced this pull request Aug 14, 2026
## 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](DataDog/dd-trace-java#11355),
[libdatadog](DataDog/libdatadog#1979),
[Go](DataDog/dd-trace-go#4753),
[Python](DataDog/dd-trace-py#19390),
[JavaScript](DataDog/dd-trace-js#8441), and
[Ruby](DataDog/dd-trace-rb#5742).

## Changes

- Replace the legacy copied fixtures with a generated, checked-in
snapshot from `DataDog/ffe-system-test-data`.
- Record the exact upstream commit in `SOURCE.md`.
- Add a script that fetches, validates, and copies the canonical
configuration and evaluation cases.
- Add a weekly and manually dispatchable workflow that opens a signed
draft dependency PR only when fixture contents have changed.
- Parse flags independently so malformed flags do not reject valid
neighbors.
- Return `FLAG_NOT_FOUND` for missing flags and classify temporal,
static, and split allocations.
- Assert canonical values and reasons through the existing .NET
unit-test suite.

## Fixture update flow

When we add or change shared evaluator behavior, I imagine the flow
working like this:

1. Add the new configuration and evaluation cases to
[`DataDog/ffe-system-test-data`](https://github.com/DataDog/ffe-system-test-data)
and review the expected behavior there.
2. The weekly updater, or a manually dispatched run for a specific ref,
fetches the canonical repository and compares its fixture contents with
the checked-in .NET snapshot.
3. If nothing changed, the workflow exits without opening or updating a
PR.
4. If fixtures changed, the workflow copies them into this repository,
records the source commit, and opens a signed draft PR with the normal
dependency labels.
5. The .NET unit tests run against the updated cases. New tests may
intentionally fail when they catch an evaluator bug or unsupported
behavior.
6. Address those evaluator failures in the same dependency PR, keeping
the fixture expectations unchanged unless the shared expectation itself
is incorrect.
7. Merge the update once the .NET evaluator satisfies the new canonical
cases.

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-data` remains the canonical source of shared
evaluator behavior.
- Keep the generated snapshot checked in so local and CI unit tests do
not require network access or submodule initialization.
- Use a scheduled dependency-update workflow instead of a git submodule.
- Treat failures introduced by new canonical fixtures as useful
regression signals and fix the evaluator as part of accepting the
update.
- Do not create a PR when the canonical fixture contents are unchanged,
even if the upstream repository has unrelated commits.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants