Skip to content

Enable EVP flagevaluation system tests for Ruby#7184

Open
leoromanovsky wants to merge 12 commits into
mainfrom
leo.romanovsky/ffe-evp-flagevaluation-enable-ruby-clean
Open

Enable EVP flagevaluation system tests for Ruby#7184
leoromanovsky wants to merge 12 commits into
mainfrom
leo.romanovsky/ffe-evp-flagevaluation-enable-ruby-clean

Conversation

@leoromanovsky

@leoromanovsky leoromanovsky commented Jun 20, 2026

Copy link
Copy Markdown
Contributor

Motivation

Ruby's SDK support for server-side EVP flagevaluation is merged in DataDog/dd-trace-rb#5896. This PR enables the shared system-tests contract for the Ruby rails72 weblog so reviewers can validate that Ruby evaluations produce the same Agent-visible EVP signal as the other SDKs.

This is primarily a manifest activation. The one shared test adjustment is included because the main degradation workload does not reliably exercise the degradation contract for Ruby: with only the manifest enabled, main sends 10,000 + 2,000 = 12,000 targeting keys in one /ffe request, the weblog returns 200, but the test times out waiting for >= 12,000 EVP evaluations. In the local failure, the Agent captured 7,168 evaluations and 0 degraded evaluations, so the test never crossed the production 10,000 full-detail cap.

Changes

  • Enables tests/ffe/test_flag_eval_evp.py for the validated Ruby rails72 weblog in manifests/ruby.yml at v2.37.0-dev; other Ruby weblogs remain irrelevant.
  • Adjusts the shared degradation workload from 12,000 evaluations in one request to 10,050 evaluations sent as bounded batches: 10 x 1,000 plus 1 x 50.
  • Keeps the degradation math explicit: 10,000 full-detail evaluations prove the production cap, and the 50 overflow evaluations must land in degraded buckets.
  • Keeps the EVP path constant aligned with the merged system-tests contract: /api/v2/flagevaluation.

Decisions

  • Enable only rails72 for EVP flagevaluation; broader non-metric OpenFeature evaluation coverage for older Ruby weblogs remains separate.
  • Treat the degradation case as an SDK aggregation contract check, not a large-request throughput or async drain benchmark.
  • Keep the workload just above the production cap because more overflow does not increase contract coverage; it only increases system-test delivery pressure.

Validation

  • Main workload check, with Ruby manifest enabled and tests/ffe/test_flag_eval_evp.py restored to origin/main:
    TEST_LIBRARY=ruby WEBLOG_VARIANT=rails72 ./run.sh +v +l ruby FEATURE_FLAGGING_AND_EXPERIMENTATION ++ -k "Test_FFE_EVP_Flagevaluation_Degradation"
    Failed: timed out waiting for >= 12000; captured payload summary was total_evaluations=7168, degraded_evaluations=0.
  • Adjusted degradation check:
    TEST_LIBRARY=ruby WEBLOG_VARIANT=rails72 ./run.sh +v +l ruby FEATURE_FLAGGING_AND_EXPERIMENTATION ++ -k "Test_FFE_EVP_Flagevaluation_Degradation"
    Passed: 1 passed, 2648 deselected in 34.04s.
  • Full Ruby EVP class:
    TEST_LIBRARY=ruby WEBLOG_VARIANT=rails72 ./run.sh +v +l ruby FEATURE_FLAGGING_AND_EXPERIMENTATION ++ -k "Test_FFE_EVP_Flagevaluation"
    Passed: 8 passed, 2641 deselected in 62.83s; captured payload summary for degradation was total_evaluations=10050, visible_evaluations=10000, degraded_evaluations=50.

@github-actions

github-actions Bot commented Jun 20, 2026

Copy link
Copy Markdown
Contributor

CODEOWNERS have been resolved as:

manifests/ruby.yml                                                      @DataDog/ruby-guild @DataDog/asm-ruby
tests/ffe/test_flag_eval_evp.py                                         @DataDog/feature-flagging-and-experimentation-sdk @DataDog/system-tests-core

@datadog-prod-us1-4

datadog-prod-us1-4 Bot commented Jun 20, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

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

@datadog-system-tests-org

datadog-system-tests-org Bot commented Jun 20, 2026

Copy link
Copy Markdown

Pipelines

⚠️ Warnings

🚦 2 Pipeline jobs failed

Testing the test | System Tests (ruby, dev) / End-to-end #1 / rails72 1   View in Datadog   GitHub Actions

Testing the test | all-jobs-are-green   View in Datadog   GitHub Actions

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 7b30ebb | Docs | Give us feedback!

Base automatically changed from leo.romanovsky/ffe-evp-flagevaluation-contract-fix to main June 22, 2026 19:40
…p-flagevaluation-enable-ruby-clean

# Conflicts:
#	tests/ffe/test_flag_eval_evp.py
@leoromanovsky leoromanovsky marked this pull request as ready for review July 1, 2026 12:50
@leoromanovsky leoromanovsky requested review from a team as code owners July 1, 2026 12:50
@leoromanovsky leoromanovsky requested review from dd-oleksii and sameerank and removed request for a team July 1, 2026 12:50

@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: 684efe67c3

ℹ️ 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 on lines +475 to +477
anchor_response = evaluate_flag(anchor_flag_key, targeting_key="evp-degradation-window-anchor")
assert anchor_response.status_code == 200, f"Window anchor request failed: {anchor_response.text}"
wait_for_evp_flagevaluation_event(anchor_flag_key)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Move anchor checks out of setup

In the FEATURE_FLAGGING_AND_EXPERIMENTATION end-to-end scenario, this setup can now fail before pytest reaches the matching test: the response assertion and wait_for_evp_flagevaluation_event() both run inside setup_, and that helper asserts after 30s. .cursor/rules/pr-review.mdc says setup_* methods must not fail because a setup failure aborts the whole scenario; if the anchor request returns non-200 or the agent payload is delayed, unrelated FFE tests in the scenario will not run. Store the anchor result and assert/wait from test_ffe_evp_flagevaluation_degradation instead.

Useful? React with 👍 / 👎.

)
]
if batch_start + EVP_DEGRADATION_BATCH_SIZE < self.eval_count:
time.sleep(EVP_DEGRADATION_BATCH_PAUSE_SECONDS)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Remove the setup sleep

This fixed sleep runs in setup_ffe_evp_flagevaluation_degradation between every batch in an end-to-end scenario. .cursor/rules/pr-review.mdc explicitly forbids time.sleep() or explicit waits inside setup_ methods because setup is only for trace generation and timing should be handled by scenario/interface timeouts; this adds fixed delay to the scenario and makes the result depend on pacing in setup. Please move the waiting/pacing into validation or scenario configuration.

Useful? React with 👍 / 👎.

@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.

🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants