feat(flags): evaluate dynamic offline rules (FFL-2837 PR2)

[btthomas]

Pull request stack

1. Plan PR (#1345)
2. PR1: Rules engine boundary (#1346)
3. PR2: Dynamic offline evaluation (feat(flags): evaluate dynamic offline rules (FFL-2837 PR2) #1347) <- you are here
4. PR3: Provider API and documentation (#1348)

This description uses Simplified Technical English. Technical names and API names do not change.

Summary

This PR adds dynamic and mixed offline evaluation to FlagsClient.

• It stores precomputed and rules branches independently.
• It keeps a valid branch when its sibling is invalid.
• It preserves branch and flag parse errors.
• It accepts each context when valid rules are available.
• It preserves a missing targeting key.
• It uses matching precomputed data first.
• It uses valid rules data second.
• It returns the applicable configuration error when no path is usable.
• It maps rules results to FlagDetails.
• It converts real assignments to TrackableAssignment.
• It keeps online and valid precomputed behavior unchanged.

Result behavior

• A malformed flag in matching precomputed data returns PARSE_ERROR before rules fallback.
• A malformed reached rules flag returns PARSE_ERROR.
• An absent flag returns FLAG_NOT_FOUND.
• A missing targeting key stays missing.
• An empty targeting key is a real value.
• Integer and numeric rules variations use the OpenFeature type number.
• An unsafe integer returns PARSE_ERROR instead of an imprecise number.

Tracking

A successful rules assignment uses the existing native assignment bridge.

• The SDK calls the bridge for each real assignment.
• A false doLog value does not stop the bridge call.
• Native code applies doLog to the exposure event.
• The SDK supplies an empty extraLogging object because the current Android bridge requires it.
• Error and default results are not tracked.

Temporary upstream code

This PR adds one TODO(FFL-2837) marker. The stacked PR2 branch contains 16 markers.

The new marker keeps the temporary rulesBased compatibility shape until a published flagging-core release contains openfeature-js-client#344 through 939da97 and the required SHA digest validation follow-up.

openfeature-js-client#336 is currently at 6d3d6a4. Its latest change only restacks it on PR #344. Its valid-sibling and error precedence remain the parity reference.

User impact

The existing offline client can evaluate rules after a context change. It does not fetch data. Matching precomputed data still has priority.

PR3 connects the provider resolution context to this path and adds customer documentation.

Checks

• Core type checks
• Targeted ESLint and formatting checks
• 7 targeted Jest suites
• 125 targeted tests

[sameerank]

According to the PR description

A flag that the upstream parser removes returns FLAG_NOT_FOUND

Once we consume the parser from DataDog/openfeature-js-client#344, malformed known flags should be preserved in precomputed.flagErrors and resolve to the coded default with PARSE_ERROR, matching core/browser. I see this PR already handles flagErrors before this fallback. Can you update the description and add an integration test using the upstream parser output?

[sameerank]

I think this should include PARSE_ERROR and should map to OpenFeature’s ParseError. Reserve GENERAL for failures that are more unexpected and harder to classify

[datadog-prod-us1-5]

 

✨ Unblock PR with BitsAI

⚠️ Warnings

🚦 1 Pipeline job failed

DataDog/dd-sdk-reactnative | test:build     

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

Useful? React with 👍 / 👎

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