FFL-1460 FlagsClient changes to accommodate Flags RN SDK sync flag evals #3049

yugisu-flux · 2025-12-11T10:53:07Z

What does this PR do?

This PR introduces new exposed "internal" APIs supporting the upcoming Flags SDK for React Native.

Changes:

New "internal" method for retrieving a snapshot of all precomputed flags to FlagsClient
New "internal" method for tracking a flag evaluation within a certain EvaluationContext
Add a _FlagsInternalProxy class for FlagsClient
Add an UnparsedFlag interface to prevent PrecomputedFlag from being exposed to the public

"internal" APIs = exposed APIs that are added purely for consumption within the RN SDK. This implementation follows the example of _RumInternalProxy.

Motivation

The motivation for this work is to allow the upcoming Flags RN SDK to retrieve the complete feature flags state snapshot from the JS side at SDK init time (FFL-1460).

Additional Notes

I've been developing these changes using the example application in the dd-sdk-reactnative repo (by leveraging composite builds)

Sibling PRs in the React Native and iOS repos:

Review checklist (to be filled by reviewers)

Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
Make sure you discussed the feature or bugfix with the maintaining team in an Issue
Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

…nd tracking evaluations

0xnm · 2025-12-12T06:52:46Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/FlagValueConverter.kt

            @Suppress("UNCHECKED_CAST")
            val result: T? = when (targetType) {
                Boolean::class -> variationValue.lowercase(Locale.US).toBooleanStrictOrNull() as? T
+


this is a redundant change, you need to run KtLint version 0.50.0:

ktlint-0.50.0 -F "**/*.kt" "**/*.kts" '!**/build/generated/**' '!**/build/kspCaches/**'

0xnm · 2025-12-12T07:01:41Z

features/dd-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/FlagsClient.kt

+    @Suppress("FunctionName")
+    @JvmSynthetic
+    fun _getInternal(): _FlagsInternalProxy?


I would propose to remove this method: it will still show up in the suggestions dropdown in Kotlin.

One can create an instance of _FlagsInternalProxy by themselves, the constructor is public there.

RUM subpackage does the same in RumMonitor. This seemed like an established pattern in the codebase so I mimicked it in the flags package

This was a first try to expose private APIs, but this still leaks it to the suggestions dropdown in case of Kotlin (not in Java though), so it is better simply to remove this and go through the manual call of _FlagsInternalProxy constructor.

0xnm · 2025-12-12T07:05:51Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+    private val internalProxy = _FlagsInternalProxy(this)
+
+    override fun _getInternal(): _FlagsInternalProxy = internalProxy


both can be removed

0xnm · 2025-12-12T07:10:27Z

...dk-android-flags/src/main/kotlin/com/datadog/android/flags/model/PrecomputedFlagConstants.kt

Seems like moving this class is not necessary? It still stays internal. Can you please rollback this change?

typotter · 2025-12-12T12:58:19Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+    }
+
+    private fun <T : Any> trackResolution(
+        flagKey: String,


Flag Value is a member of the precomputed flag.

typotter · 2025-12-12T13:04:49Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+     *
+     * @return A map of flag key to precomputed flag, or null if no flags are available.
+     */
+    internal fun getFlagAssignmentsSnapshot(): Map<String, PrecomputedFlag>? = flagsRepository.getFlagsSnapshot()


Where does the caller get the EvaluationContext from?
What do you think of

interface FlagAssignmentSnapshot { Map<String, ResolutionDetails> flagAssignments EvaluationContext: context }

Then, the track method would be

trackResolution(flagKey, flagAssignmentsSnapshot)

The trackResolution method would look up the resolution for that flag from the snapshot and the context for tracking.

The context is stored on JavaScript side alongside with flags cache, and is being sent from there.

typotter · 2025-12-12T13:06:24Z

...ures/dd-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/model/PrecomputedFlag.kt

+ * @param reason The evaluation reason.
+ */
+@InternalApi
+data class PrecomputedFlag(


Which of these fields are needed for including in the Flag Assignments snapshot? I'd prefer to keep an internal model as this specifically represents when we are sending "over the wire" from the edge assignments server to the SDK.
I think ResolutionDetails should have what you need and it's already public.

ResolutionDetails doesn't have the doLog property from PrecomputedFlag, which is required in the trackResolution method

Synced on this and agreed to make an external Interface that we implement with our internal data class. This avoids a lot of unnecessary fieldmapping code

…ta class

features/dd-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/_FlagsInternalProxy.kt

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

...dk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/model/PrecomputedFlag.kt

yugisu-flux · 2025-12-16T13:43:21Z

features/dd-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/model/UnparsedFlag.kt

+ */
+@InternalApi
+@Suppress("UndocumentedPublicProperty")
+interface UnparsedFlag {


TBH I don't really like this naming, open to better name ideas 🙏

I think PrecomputedFlag or FlagAssignment would work here. We don't really need to say that it's "unparsed" because the flag assignment itself has been parsed from the server response. It's just that the value has not been typed yet and that's more of an internal concern.

0xnm

I added some suggestions, nothing blocking, mostly about API/logging. I think it is a final round and we are good to go after.

0xnm · 2025-12-16T13:49:41Z

features/dd-sdk-android-flags/api/apiSurface

  fun removeListener(FlagsStateListener)
+class com.datadog.android.flags._FlagsInternalProxy
+  constructor(FlagsClient)
+  fun getFlagAssignmentsSnapshot(): Map<String, com.datadog.android.flags.model.UnparsedFlag>?


Minor: normally returning nullable collection should be avoided, it is better to return empty collection if there is nothing to return. This way there is no null case to handle at the call site.

If the returned collection is null, that means the client initialization has failed at some step. Do you have an alternative to handle the case of the clear failure vs the flags cache is empty so we return an empty collection?

I guess the alternatives would be an pattern Optional (feels better than returning null?) or throwing an exception from this method (personally I don't like this pattern).

I think for the client initialization we now have FlagsClientState and FlagsClient.state.getCurrentState API, so I wouldn't rely on the null value here to make a state judgement. If RN needs to know the state it is better to use that API.

0xnm · 2025-12-16T13:50:00Z

features/dd-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/_FlagsInternalProxy.kt

+    fun getFlagAssignmentsSnapshot(): Map<String, UnparsedFlag>? = if (client is DatadogFlagsClient) {
+        client.getFlagAssignmentsSnapshot()
+    } else {
+        null


Suggested change

null

emptyMap()

0xnm · 2025-12-16T13:52:11Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+                val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject - ${exception.message}"
+                featureSdkCore.internalLogger.log(
+                    InternalLogger.Level.WARN,
+                    InternalLogger.Target.MAINTAINER,
+                    { "Flag '$flagKey': $errorMessage" }
+                )


it is better to attach exception to the log call

Suggested change

val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject - ${exception.message}"

featureSdkCore.internalLogger.log(

InternalLogger.Level.WARN,

InternalLogger.Target.MAINTAINER,

{ "Flag '$flagKey': $errorMessage" }

)

val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject"

featureSdkCore.internalLogger.log(

InternalLogger.Level.WARN,

InternalLogger.Target.MAINTAINER,

{ "Flag '$flagKey': $errorMessage" },

exception

)

It seems there is a request to do another round of review, but I don't see a change related to this comment, there is only a merge of develop since last review.

Whops forgot to hit the push button

0xnm · 2025-12-16T13:53:01Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+                val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject - ${exception.message}"
+                featureSdkCore.internalLogger.log(
+                    InternalLogger.Level.WARN,
+                    InternalLogger.Target.MAINTAINER,


Should the target be the USER? Since I guess it is about user data parsing

This log is corresponding to the flags data parsing logic in readAndParseAssignment (line 289).

My point here is that MAINTAINER target logs are visible only in the SDK debug builds, they won't be shown in the release build. So if user needs to know about this error, it should be USER target.

@typotter FYI the target has been changed to USER in other related flag value parsing logic as well. Does that work for you?

0xnm · 2025-12-16T13:53:46Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+            featureSdkCore.internalLogger.log(
+                InternalLogger.Level.WARN,
+                InternalLogger.Target.MAINTAINER,
+                { "Flag '$flagKey': Failed to parse value '${flag.variationValue}' as '${flag.variationType}'" }
+            )


not sure if it is useful, because we already have a log entry above in case of exception, so if exception happens we will have two log entries about the same

This log triggers for all variation types other than JSONObject. This is made this way to avoid swallowing JSONException details and provider them in the corresponding branch.

0xnm · 2025-12-16T13:54:25Z

...lags/src/main/kotlin/com/datadog/android/flags/internal/repository/DefaultFlagsRepository.kt

+            InternalLogger.Target.USER,
+            { WARN_CONTEXT_NOT_SET }
+        )
+        return null


Suggested change

return null

return emptyMap()

0xnm · 2025-12-16T13:54:32Z

...droid-flags/src/main/kotlin/com/datadog/android/flags/internal/repository/FlagsRepository.kt

    fun setFlagsAndContext(context: EvaluationContext, flags: Map<String, PrecomputedFlag>)
    fun getPrecomputedFlagWithContext(key: String): Pair<PrecomputedFlag, EvaluationContext>?
    fun hasFlags(): Boolean
+    fun getFlagsSnapshot(): Map<String, PrecomputedFlag>?


Suggested change

fun getFlagsSnapshot(): Map<String, PrecomputedFlag>?

fun getFlagsSnapshot(): Map<String, PrecomputedFlag>

0xnm · 2025-12-16T13:56:26Z

...k-android-flags/src/test/kotlin/com/datadog/android/flags/internal/DatadogFlagsClientTest.kt

+        verify(mockProcessor).processEvent(
+            flagName = eq(fakeFlagKey),
+            context = eq(fakeContext),
+            data = eq(fakeFlag)
+        )


tip: when all matchers are eq, eq usage can be omitted

Suggested change

verify(mockProcessor).processEvent(

flagName = eq(fakeFlagKey),

context = eq(fakeContext),

data = eq(fakeFlag)

)

verify(mockProcessor).processEvent(

flagName = fakeFlagKey,

context = fakeContext,

data = fakeFlag

)

datadog-official · 2025-12-16T14:04:08Z

🎯 Code Coverage
• Patch Coverage: 75.00%
• Overall Coverage: 65.77%

View detailed report

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: b566487 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

codecov-commenter · 2025-12-16T14:08:12Z

Codecov Report

❌ Patch coverage is 86.53846% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.28%. Comparing base (ed7f4e1) to head (4eed5cb).
⚠️ Report is 4 commits behind head on develop.

Files with missing lines	Patch %	Lines
...n/com/datadog/android/flags/_FlagsInternalProxy.kt	0.00%	7 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3049      +/-   ##
===========================================
+ Coverage    71.24%   71.28%   +0.04%     
===========================================
  Files          866      867       +1     
  Lines        31730    31773      +43     
  Branches      5360     5370      +10     
===========================================
+ Hits         22604    22648      +44     
+ Misses        7602     7597       -5     
- Partials      1524     1528       +4

Files with missing lines	Coverage Δ
...tadog/android/flags/internal/DatadogFlagsClient.kt	`92.68% <100.00%> (+1.38%)`	⬆️
.../android/flags/internal/ExposureEventsProcessor.kt	`100.00% <ø> (ø)`
...og/android/flags/internal/model/PrecomputedFlag.kt	`100.00% <100.00%> (ø)`
...lags/internal/repository/DefaultFlagsRepository.kt	`69.49% <100.00%> (+5.49%)`	⬆️
...n/com/datadog/android/flags/_FlagsInternalProxy.kt	`0.00% <0.00%> (ø)`

... and 45 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

0xnm

lgtm, added some final remarks.

And I would still strongly recommend to change fun getFlagAssignmentsSnapshot(): Map<String, com.datadog.android.flags.model.UnparsedFlag>? to fun getFlagAssignmentsSnapshot(): Map<String, com.datadog.android.flags.model.UnparsedFlag>, because having a nullable collection is anti-pattern. Once it is out it will be public ABI-breaking change if type should be changed to non-nullable.

0xnm · 2025-12-17T12:14:05Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+                val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject - ${exception.message}"
+                featureSdkCore.internalLogger.log(
+                    InternalLogger.Level.WARN,
+                    InternalLogger.Target.MAINTAINER,


My point here is that MAINTAINER target logs are visible only in the SDK debug builds, they won't be shown in the release build. So if user needs to know about this error, it should be USER target.

0xnm · 2025-12-17T12:14:56Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+            VariationType.OBJECT.value -> try {
+                JSONObject(flag.variationValue)
+            } catch (exception: JSONException) {
+                val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject - ${exception.message}"


Suggested change

val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject - ${exception.message}"

val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject"

There is no need to add exception message here, it will already be shown due to passing exception object to the log call.

yugisu-flux · 2025-12-17T12:18:23Z

Changed the base branch to Tyler's branch back and forth by a mistake; I will need his callback changes in the React Native PR, not this one.

typotter · 2025-12-17T15:50:05Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+    /**
+     * Retrieves a snapshot of all flag assignments.
+     *
+     * Supposed to be used by internal Datadog packages to get flags state snapshot for a given evaluation context.


Suggested change

* Supposed to be used by internal Datadog packages to get flags state snapshot for a given evaluation context.

* Explicitly for use by the Datadog React Native SDK to get flags state snapshot for a given evaluation context.

typotter

LGTM for FFE SDK

typotter · 2025-12-17T16:11:29Z

...d-sdk-android-flags/src/main/kotlin/com/datadog/android/flags/internal/DatadogFlagsClient.kt

+        trackResolution(flagKey, flag, flagValue, context)
+    }
+
+    private fun parseFlagValueString(flagKey: String, flag: UnparsedFlag): Any {


Can you use the FlagValueConverter here?

FFL-1460 Add internal methods for retrieving a flags state snapshot a…

61e3693

…nd tracking evaluations

yugisu-flux requested a review from typotter December 11, 2025 10:53

yugisu-flux self-assigned this Dec 11, 2025

yugisu-flux requested a review from a team as a code owner December 11, 2025 10:53

yugisu-flux mentioned this pull request Dec 11, 2025

FFL-1460 FlagsClient changes to accommodate Flags RN SDK sync flag evals DataDog/dd-sdk-ios#2604

Open

4 tasks

yugisu-flux added 3 commits December 11, 2025 13:39

FFL-1460 Run ktlint

0f81db5

Move PrecomputedFlag to public, mark as InternalApi

41290fa

Update apiSurface, fix ktlint errors

ca508fe

yugisu-flux force-pushed the dima/FFL-1460-sync-flag-evaluation-in-rn-sdk branch from f3efb76 to ca508fe Compare December 11, 2025 18:01

Fis build issues

187cbd9

0xnm requested changes Dec 12, 2025

View reviewed changes

typotter reviewed Dec 12, 2025

View reviewed changes

yugisu-flux added 3 commits December 15, 2025 19:33

FFL-1460 Move PrecomputedFlagConstants back, run proper ktlint

75c21dd

FFL-1460 Remove FlagsClient._getInternal method

797b4ef

Rework the exposed internal APIs to not expose the PrecomputedFlag da…

092a703

…ta class

yugisu-flux requested review from 0xnm and typotter December 15, 2025 18:48

0xnm requested changes Dec 16, 2025

View reviewed changes

yugisu-flux added 6 commits December 16, 2025 14:53

FFL-1460 Improve error logging in the parseFlagValueString method

211d32a

FFL-1460 Remove unnecessary lint suppressions

ebd67fa

FFL-1460 Make PrecomputedFlag internal again

05570ee

FFL-1460 Address linter errors

a315d75

FFL-1460 Add tests for new exposed internal APIs

dfe9808

FFL-1460 Add tests for DefaultFlagsRepository.getFlagsSnapshot

cff21c8

yugisu-flux requested a review from 0xnm December 16, 2025 13:34

yugisu-flux commented Dec 16, 2025

View reviewed changes

0xnm reviewed Dec 16, 2025

View reviewed changes

yugisu-flux mentioned this pull request Dec 16, 2025

FFL-1460 Update Flags SDK to evaluate feature flags synchronously DataDog/dd-sdk-reactnative#1064

Draft

4 tasks

yugisu-flux and others added 3 commits December 16, 2025 18:33

Merge branch 'develop' into dima/FFL-1460-sync-flag-evaluation-in-rn-sdk

4eed5cb

FFL-1460 Remove eqs

b7e67ee

FFL-1460 Attach an exception to the log

859c55a

yugisu-flux requested a review from 0xnm December 16, 2025 17:10

yugisu-flux changed the base branch from develop to typo/FFL-1579-sdk-android-expose-callback-for-set-evaluation-context-method-call December 17, 2025 12:15

yugisu-flux changed the base branch from typo/FFL-1579-sdk-android-expose-callback-for-set-evaluation-context-method-call to develop December 17, 2025 12:16

0xnm previously approved these changes Dec 17, 2025

View reviewed changes

yugisu-flux added 2 commits December 17, 2025 14:27

FFL-1460 Don't return a nullable Map from getFlagAssignmentsSnapshot

14ae399

FFL-1460 Log updates in DatadogFlagsClient

b566487

yugisu-flux dismissed 0xnm’s stale review via b566487 December 17, 2025 12:27

0xnm approved these changes Dec 17, 2025

View reviewed changes

typotter reviewed Dec 17, 2025

View reviewed changes

typotter approved these changes Dec 17, 2025

View reviewed changes

typotter reviewed Dec 17, 2025

View reviewed changes

		private val internalProxy = _FlagsInternalProxy(this)

		override fun _getInternal(): _FlagsInternalProxy = internalProxy

	fun getFlagsSnapshot(): Map<String, PrecomputedFlag>?
	fun getFlagsSnapshot(): Map<String, PrecomputedFlag>

	val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject - ${exception.message}"
	val errorMessage = "Failed to parse value '${flag.variationValue}' as JSONObject"

	* Supposed to be used by internal Datadog packages to get flags state snapshot for a given evaluation context.
	* Explicitly for use by the Datadog React Native SDK to get flags state snapshot for a given evaluation context.

FFL-1460 FlagsClient changes to accommodate Flags RN SDK sync flag evals #3049

Are you sure you want to change the base?

FFL-1460 FlagsClient changes to accommodate Flags RN SDK sync flag evals #3049

Uh oh!

Conversation

yugisu-flux commented Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Additional Notes

Review checklist (to be filled by reviewers)

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yugisu-flux Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xnm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yugisu-flux commented Dec 11, 2025 •

edited

Loading

yugisu-flux Dec 15, 2025 •

edited

Loading

datadog-official bot commented Dec 16, 2025 •

edited by datadog-datadog-prod-us1 bot

Loading

codecov-commenter commented Dec 16, 2025 •

edited

Loading