fix(openfeature): bound flagevaluation EVP payloads

[leoromanovsky]

Motivation

The merged Go flagevaluation writer aggregates bounded rows but still needed to enforce the shared EVP 5 MiB uncompressed JSON request limit before posting. At rollout scale, one flush can exceed that limit even when aggregation cardinality is bounded, so the writer must split/degrade/drop by encoded bytes without changing customer evaluation behavior or the worker-facing schema.

Changes

• Adds a raw-byte EVP post path so the writer can split already-encoded JSON bodies before transport.
• Splits Go flagevaluation EVP POST bodies by encoded uncompressed JSON bytes under the shared EVP payload limit, including the {context, flagEvaluations} wrapper.
• Degrades an oversized full-fidelity row by omitting targeting_key and context; drops/logs only if the degraded row still cannot fit.
• Preserves aggregation caps, queue backpressure, endpoint, headers, async writer flow, and the canonical payload schema.
• Adopts the reviewed Go naming split: flagEvalMetricsHook for OTel metrics and flagEvalLoggingHook / flagEvalLoggingWriter for the EVP flagevaluation logging path.

Decisions

• Payload splitting stays in the background flagevaluation writer, not the OpenFeature evaluation hook.
• Split decisions use the same jsoniter configuration used by the EVP client so measured bytes match posted bytes.
• The writer sends several ordinary EVP requests instead of introducing a new endpoint or changing the payload schema.
• Compression is treated as a transport concern after the uncompressed 5 MiB decision.
• Hook names describe product behavior: metrics for the existing OTel counter path, logging for the EVP flagevaluation path.

flowchart TD
  A[drained aggregated rows] --> B[serialize candidate batch as JSON]
  B --> C{batch <= 5 MiB?}
  C -- yes --> D[post asynchronously through EVP proxy]
  C -- no --> E{current row fits degraded?}
  E -- yes --> F[omit targeting_key and context]
  F --> B
  E -- no --> G[drop, log, count]

Loading

Validation Evidence

System Tests

• Existing merged Go server-side EVP system-test baseline: Add EVP flagevaluation system tests system-tests#7146
• Original merged Go flagevaluation writer PR with system-test evidence: feat(openfeature): server-side EVP flagevaluation emission #4886

Staging End-To-End

• The merged Go rollout PR proved the Go SDK emits backend-indexed flagevaluation rows through the real Agent/EVP path: feat(openfeature): server-side EVP flagevaluation emission #4886
• This follow-up keeps the same route and payload schema and only bounds the writer's encoded POST bodies under the shared 5 MiB EVP limit.

Related PRs

• Original merged Go flagevaluation writer PR: feat(openfeature): server-side EVP flagevaluation emission #4886
• Go naming PR from Oleksii: refactor(openfeature): disambiguate eval metrics and logging hooks #4937

[datadog-official]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 81.06%
• Overall Coverage: 62.99% (+0.04%)

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

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-07-01 14:03:18

Comparing candidate commit f4aa84f in PR branch leo.romanovsky/ffl-2446-evp-flagevaluation-go-limit with baseline commit baa5573 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 297 metrics, 2 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

[codecov]

Codecov Report

❌ Patch coverage is 77.66990% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.56%. Comparing base (baa5573) to head (d3ab3b3).

Files with missing lines	Patch %	Lines
openfeature/flageval_logging.go	82.95%	8 Missing and 7 partials ⚠️
openfeature/evp.go	46.66%	4 Missing and 4 partials ⚠️

Additional details and impacted files

Files with missing lines	Coverage Δ
internal/llmobs/llmobs.go	81.80% <ø> (ø)
openfeature/evp.go	58.69% <46.66%> (ø)
openfeature/flageval_logging.go	86.58% <82.95%> (ø)

... and 464 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.

[vjfridge]

LGTM! Left some food for thought but no hard blockers. Thanks for taking this on!

[leoromanovsky]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-07-01 12:45:45 UTC ℹ️ Start processing command /merge

---

2026-07-01 12:45:53 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.

---

2026-07-01 13:10:16 UTC ⚠️ MergeQueue: This merge request was unqueued

leo.romanovsky@datadoghq.com unqueued this merge request

[genesor]

LGTM, One question around the size limit.

[genesor]

Out of curiosity, I'm trying to understand why PayloadSizeLimit = 5 * 1024 * 1024 (5,242,880 bytes) and EventSizeLimit = 5_000_000 (5,000,000 bytes) differ by ~243 KB ?

[leoromanovsky]

Thank you for bringing this up! I tried to be as minimally disruptive as possible and not change the LLMObs product, but my suspicion is that EventSizeLimit = 5_000_000 is not exactly correct. My intuition is that the real value is a multiple of a megabyte. I double-checked the agent and the real limit seems to be 10MB; updating here but still leaving LLMObs as-is.