[aarsilv]

Motivation

The dependent-flags suite leaves the root error code unspecified for missing prerequisites, depth-limit failures and cycles. dependent-atomic-error-root, dependent-depth-three-root and dependent-cycle-a check reason ERROR and the caller's default value, but not the error code. Implementations differ: some copy the prerequisite's code to the root (FLAG_NOT_FOUND when the prerequisite is missing), and others return GENERAL.

GENERAL is the better root code. The root flag exists, so FLAG_NOT_FOUND on the root reports a flag-not-found error for a flag that is configured. dependent-no-assignment-root already expects GENERAL for the root and for the failed parent.

Changes

• Add "errorCode": "GENERAL" to the results of dependent-atomic-error-root, dependent-depth-three-root and dependent-cycle-a.
• Document the rule in the README: the root returns the caller default with reason ERROR and error code GENERAL, and the failed prerequisite's own evaluation event keeps its specific code. This PR does not add evaluation-event matchers to these three cases.

Native implementations checked

Implementation	Revision	Result
JS core	DataDog/openfeature-js-client#453 at 12fe487	Shared-suite runner with this change: 15 of 15 tests pass (the 14 cases plus one matcher test). Control: expecting FLAG_NOT_FOUND on the atomic root fails.
libdatadog (used by Python, Ruby and PHP)	DataDog/libdatadog#2748 at 983b4b0, with the dependent-flags suite runner proposed in its review	The suite passes. Control: expecting FLAG_NOT_FOUND on the atomic root fails (actual GENERAL).
Go	DataDog/dd-trace-go#5799 at ed55d61	A root with a missing prerequisite returns GENERAL (probe). No shared-suite runner yet.
Java	DataDog/dd-trace-java#13166 at f1976f6	The root returns GENERAL for prerequisite failures (module tests).
.NET	DataDog/dd-trace-dotnet#9589 at 3ed5311	Returns FLAG_NOT_FOUND for the atomic root (probe), so it needs a change.

JS and libdatadog were run against the modified fixtures. The Go, Java and .NET results come from earlier probes and native tests; those implementations were not rerun against this change. The Go and Java native tests also cover depth-limit and cycle errors, and a .NET depth-limit probe returned GENERAL.

#62 expects FLAG_NOT_FOUND for the root in its precomputed dependent-flags fixture. If this rule is accepted, that fixture should follow it.

Testing

• python3 ci/validate-fixtures.py: 2 evaluation suites, 381 evaluation cases across 48 files.
• python3 -m unittest ci/test_validate_fixtures.py: OK.

🤖 Generated with Claude Code

[hhan2024]

I wonder if our public documentation will need to surface this for how error codes work with dependent flags

[typotter]

🤖 Comment from Codex working with @typotter:

[P1] Add evaluation-event expectations for the atomic failure case.

This result assertion verifies that the requested root uses GENERAL, but the case has no evaluationEvents matcher. An implementation can therefore change the missing prerequisite's event from FLAG_NOT_FOUND to GENERAL and still pass this fixture, although the README requires the prerequisite to keep its specific error.

Please make the atomic case assert the successful leaf event, the missing prerequisite with FLAG_NOT_FOUND, the requested root with GENERAL, no exposures, and noUnmatchedEvents: true. This case has no intermediate ancestor, so it can enforce the distinction without depending on the transitive-error decision.

[typotter]

🤖 Comment from Codex working with @typotter:

[P2] Define the error code for configured intermediate ancestors.

This wording does not classify a transitive graph such as requested root → configured parent → missing leaf. The configured parent is both a prerequisite of the requested root and the root of its own failed dependency evaluation.

Please state that a specific error code applies only to the node where that error originates. A missing node therefore uses FLAG_NOT_FOUND, while every configured ancestor that fails because of it, including intermediate flags and the requested root, uses GENERAL. A transitive fixture can then enforce this rule without relying on implementation precedent.