Fix temporal allocation reasons#15
Merged
leoromanovsky merged 2 commits intoJun 12, 2026
Merged
Conversation
leoromanovsky
marked this pull request as ready for review
June 12, 2026 03:11
leoromanovsky
requested review from
dd-oleksii,
greghuels and
sameerank
and removed request for
a team
June 12, 2026 03:11
sameerank
approved these changes
Jun 12, 2026
dd-oleksii
reviewed
Jun 12, 2026
dd-oleksii
left a comment
dd-oleksii
left a comment
Member
There was a problem hiding this comment.
We actually want DEFAULT in those cases. See the doc
Collaborator
Author
@dd-oleksii Thanks for linking that! |
leoromanovsky
changed the title
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
to DataDog/libdatadog
that referenced
this pull request
Jun 12, 2026
## Motivation The shared FFE fixtures now assert result metadata beyond returned values, including `reason` and `errorCode`. libdatadog was only checking fixture values, so it could accept shared fixture bumps while still drifting on public assignment metadata. The latest `ffe-system-test-data` main also corrects temporal allocation fixtures to expect `DEFAULT` for active date-window-only allocations. Those allocations return a configured platform/default value, but no targeting rule matched and no non-vacuous split selected the subject. ## Changes This updates the `ffe-system-test-data` submodule through `d9d8020`, including the merged temporal reason correction from DataDog/ffe-system-test-data#15. The canonical fixture harness now asserts fixture-provided `reason` and `errorCode` fields in addition to values. Invalid or unsupported per-flag config is represented as a distinct evaluation error that maps to caller-default behavior while preserving isolation for valid flags in the same payload. The evaluator now has an explicit `AssignmentReason::Default` for successful default/platform assignments. Active temporal allocations with no rules and no effective split now report `DEFAULT`, and the FFI mapping exposes that as `ddog_ffe_Reason::Default`. ## Decisions Top-level configuration parse behavior is unchanged: a malformed full payload still fails configuration creation, while malformed individual flags are isolated and evaluate to caller defaults. Missing flags continue to report `FLAG_NOT_FOUND`. Optional `errorCode` fixture assertions remain optional because some existing shared cases omit that field even when the reason is `ERROR`. Validation: - `cargo +nightly-2026-02-08 fmt --all -- --check` - `cargo check -p datadog-ffe -p datadog-ffe-ffi -p datadog-ffe-test-suite` - `cargo nextest run -p datadog-ffe -p datadog-ffe-ffi -p datadog-ffe-test-suite --no-fail-fast` - `cargo test --doc -p datadog-ffe -p datadog-ffe-ffi -p datadog-ffe-test-suite` - `cargo +stable clippy -p datadog-ffe -p datadog-ffe-ffi -p datadog-ffe-test-suite --all-targets --all-features -- -D warnings` - Earlier on this branch: `cargo +stable clippy --workspace --all-targets --all-features -- -D warnings` - Earlier on this branch: `cargo ffi-test` built the FFI artifacts and the `ffe` example passed; the overall command failed in the unrelated `crashtracking` example with signal 5. Co-authored-by: leo.romanovsky <leo.romanovsky@datadoghq.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The date-window fixtures currently expect
STATICfor allocations that only become active because theirstartAt/endAtscheduling window allows them. The evaluation reasons RFC says date-window fields are scheduling metadata, not targeting rules: they do not implyTARGETING_MATCH, but their presence means the result is not trulySTATICeither.Keeping these shared fixtures stale lets SDK and precompute implementations drift on the public assignment reason field even when the selected value is correct.
Changes and Decisions
This PR updates only the existing temporal evaluation fixtures for
start-and-end-date-testandmicrosecond-date-test. The expected values are unchanged; only the successful assignment reason moves fromSTATICtoDEFAULT.This matches the RFC rule for active date-window-only allocations: the active allocation returns a platform value, no targeting rule matched, no non-vacuous split resolved the subject, and date bounds preclude
STATIC.This is split from the broader precompute contract fixture PR so the behavior correction can be reviewed and merged independently.
Validation
Downstream validation is performed by dd-source/libdatadog-style evaluator tests that consume these fixtures and compare assignment outputs against the shared contract.