Repository navigation
Conversation
The JSON rules-based/server endpoint of the mocked backend now accepts selected_flag_tags and selected_flag_key_patterns, applies them to the shared ufc-config.json with the shared tags file, and sends DD-Flag-Selection-Ignored with the full configuration for an invalid selection, following ffe-service semantics. A test-only control forces an ignored reason. The fixture sync vendors flag-selection/ from ffe-system-test-data. A new parametric test, under the new feature_flags_configuration_filtering feature, checks that a server SDK sends a tag selection and serves only the selected flags. Every manifest gates it until each SDK ships the provider option.
|
|
The fixture sync copies flag-selection/selection-vectors.json and flag-selection/ufc-config-tags.json instead of the whole directory, so the upstream README stays out of the snapshot. The copy stays outside _copy_fixture_snapshot.
A valid selection whose value decodes to bytes that are not UTF-8, such as selected_flag_tags=%85, made the selection ETag digest raise, so the mock dropped the connection. ffe-service applies such a selection. The digest now hashes the values' wire bytes. The flag selection test also waits while the provider reports no configuration through providerState.hasConfig, like the other FFE tests.
🎉 All green!🧪 All tests passed 🔗 Commit SHA: 4b7487c | Docs | View more details | Give us feedback! |
The PHP parametric app loads ffe_start's configuration as a UFC, so a selection nested in it would collide with tests that pass a UFC there. ffe_start now takes flag_selection and sends it as its own field, as is. The test app passes it untouched to the SDK's provider option; only the SDK canonicalizes and validates it.
ffe-service folds the selection into the ETag, so a 304 for a selection carries the same validator as its 200. The mocked backend's scripted 304 now does the same: under a valid selection it answers 304 only when If-None-Match carries that selection's ETag, and serves the selected flags otherwise. Without a selection the scripted 304 is unchanged. The flag selection test also checks that the SDK's next poll sends the selection's ETag back.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ed97cad3f3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
The flag selection test now runs the ffe-system-test-data flag-selection suite, one test per case file: tags, key patterns, both, canonical form, a tag with interior whitespace, an empty selection, two SDK drops and a selection the server ignores. Each file starts the provider with its raw selection, checks the configuration request against the file's expected canonical selection, then evaluates its cases. The ETag revalidation check stays its own test. The suite is served by the mocked backend: client.ffe_use_suite(name) switches the agentless JSON configuration to that suite's UFC and filters selections with its flag-tags.json. Suites otherwise reach SDKs through Remote Config, which ignores selections. The root UFC no longer has tags. The fixture sync vendors only selection-vectors.json under flag-selection/ and accepts flag-tags.json in a suite. The snapshot is refreshed from DataDog/ffe-system-test-data@be2ab83.
… data A request carrying a selection the mocked backend ignores got a scripted 304 whatever its If-None-Match, so an SDK that had cached a filtered body kept it instead of receiving every flag and the ignored reason. Any request with selection parameters now gets a scripted 304 only for the ETag of the body it would otherwise receive. Requests without a selection keep the unconditional scripted 304. The fixture sync also checks the entries of selection-vectors.json and a suite's flag-tags.json, not only their top-level keys, before replacing the snapshot.
Motivation
Server SDKs send a flag selection (tags and key patterns) on the agentless
GET /api/v2/feature-flagging/config/rules-based/serverrequest, and serve only the flags the backend returns. The mocked backend can't exercise this today: any query parameter besidesdd_envgets a 404, the UFC is never narrowed, andDD-Flag-Selection-Ignoredis never sent.Jira: FFL-3567
Depends on DataDog/ffe-system-test-data#63, which adds the
flag-selectionevaluation suite this test runs.Changes
rules-based/serverendpoint only; the protobuf helpers are unchanged):selected_flag_tagsandselected_flag_key_patternsalongsidedd_env=test. Any other query still gets a 404.domains/ffe/libs/flagging/selection/selection.go):QueryUnescapedecoding;client.ffe_use_suite(name)serves that ffe-system-test-data evaluation suite'sufc-config.jsoninstead of the root UFC, and matches tags from the suite'sflag-tags.json. It accepts only suites in the snapshot; reset restores the root UFC, which has no tags. Suites otherwise reach SDKs through Remote Config, which ignores selections.ufc-v1-<suite>-<digest>), as ffe-service folds the selection into its ETag. A request carrying a selection, applied or ignored, gets a scriptednot_modified304 only whenIf-None-Matchcarries the ETag of the body it would otherwise get, and gets that body otherwise. Without a selection, the scripted 304 is unchanged.DD-Flag-Selection-Ignored: <reason>.client.ffe_set_flag_selection_ignored_reason(...)forces an ignored reason (for exampletag_load_failed) on valid selections. Reset clears it.evaluation-suites/.update_ffe_fixtures.pyvendorsflag-selection/selection-vectors.json(the same way [FFL-3364] Test standalone Node rules flag selection #8266 does) and accepts an optionalflag-tags.jsonin a suite. It checks the entries of both files before replacing the snapshot.evaluation-suites/flag-selection/arrives through the existing suite copy. The snapshot comes from DataDog/ffe-system-test-data@be2ab83, the head of Some clean up on decorators #63.tests/parametric/test_ffe/test_flag_selection.py:Test_FFE_Flag_Selection::test_flag_selection_suiteruns once per suite case file. It selects the suite and any forced ignored reason on the mock, starts the provider in agentless mode with the file's raw selection, checks the first configuration request against the file'sexpectations.configurationRequest, then evaluates each case that applies to the platform.ffe_start(flag_selection=...), which sends it as is in its own/ffe/startfield,flag_selection, separate fromconfiguration(which the PHP app loads as a UFC). The Node.js test app builds its provider at boot, so the test also setsSYSTEM_TESTS_FFE_FLAG_SELECTION(the selection as JSON) inlibrary_envfor it. Test apps pass the value untouched; only the SDK canonicalizes and validates it. No test app reads either yet; FFL-3576 wires them.Test_FFE_Flag_Selection_Revalidationchecks that the SDK's next poll sends its selection's ETag back inIf-None-Match.tests/test_the_test/test_mock_ffe_flag_selection.py, with tests forffe_use_suite.feature_flags_configuration_filteringuses the not-reported placeholder ID (NOT_REPORTED_ID, -1) until someone with Feature Parity Dashboard access, such as the system-tests team, creates the entry; the real ID and dashboard link then replace it. Every parametric manifest gatestest_flag_selection.py:missing_featurefor the SDKs with FFE,irrelevantfor cpp and rust.docs/mocked_backend/README.mddocuments the selection behavior andffe_use_suite.After DataDog/ffe-system-test-data#63 merges, the vendored snapshot and
SOURCE.mdget re-synced withupdate_ffe_fixtures.pyfrom the merged commit.Overlap with open PRs: #8266 also vendors
selection-vectors.jsonand editsupdate_ffe_fixtures.pyand its tests. Whichever of the two merges second merges main in (no force-push) and resolves the overlap. #8266's protobuf rules tests stay unfiltered.Validation:
./run.sh TEST_THE_TESTon the FFE mock, agentless, rules-backend, mock-backend, fixture-sync, FFE, feature and manifest suites: 347 passed../format.sh --checkpasses.-F: the six case files that send a selection and the revalidation test fail at the request assertion, because Go sends onlydd_env. The three files where the SDK must send no selection (empty selection, too many values, long URL) pass: an SDK without the option sends none and gets every flag. Without-F: 7 xfailed, 3 xpassed.Workflow
system-tests-reviewers: ask to one of youre co-worker familiar with the tested feature.system-tests-core(slack)🚀 Once your PR is reviewed and the CI green, you can merge it!
🛟 #apm-shared-testing 🛟