[FFL-1720] Evaluation Logging: Integration

[typotter]

🥞 Evaluation Logging Stacked Pull Requests 🥞

👉 Integration & Configuration (this PR)
☑️ Storage & Network Infrastructure (PR #3146)
☑️ Aggregation Engine & Test Utilities (PR #3145)
☑️ FlagEvaluation Schema (PR #3166)
☑️ Event Schema & Data Models (PR #3144)
☑️ Evaluations Subfeature (PR #3159)
⎿ feature/flags-evaluations-logging (feature branch)

Datadog Internal
🎟️ Ticket: FFL-1720 - Implement Evaluation Logging for Android SDK

What does this PR do?

Wires the evaluation logging feature end-to-end by connecting the EvaluationsFeature to the flag evaluation flow. This is the final PR that enables evaluation logging in the Flags SDK.

Motivation

We need to implement Evaluation Logging to provide comprehensive visibility into all feature flag evaluations, including defaults, errors, and successful matches. This goes beyond exposure logging by capturing aggregated metrics about evaluation frequency, error rates, and runtime default usage across all flags.

Additional Notes

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)

[typotter]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [FFL-1720] Evaluation Logging: Integration #3147 👈 (View in Graphite)
• [FFL-1720] Evaluation Logging: Storage & Network Infrastructure #3146
• [FFL-1720] Evaluation Logging: Aggregation Engine & Test Utilities #3145
• [FFL-1720] Evaluation Logging: Event Schema & Data Models #3144
• feature/flags-evaluations-logging

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 33.75000% with 53 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.92%. Comparing base (8ade2db) to head (9b092dc).

Files with missing lines	Patch %	Lines
...tadog/android/flags/internal/EvaluationsFeature.kt	2.44%	40 Missing ⚠️
...tadog/android/flags/internal/DatadogFlagsClient.kt	67.86%	6 Missing and 3 partials ⚠️
...in/kotlin/com/datadog/android/flags/FlagsClient.kt	33.33%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@                          Coverage Diff                          @@
##           typo/FFL-1720-pr3-storage-network    #3147      +/-   ##
=====================================================================
- Coverage                              71.00%   70.92%   -0.08%     
=====================================================================
  Files                                    906      906              
  Lines                                  33354    33428      +74     
  Branches                                5624     5641      +17     
=====================================================================
+ Hits                                   23681    23706      +25     
- Misses                                  8106     8148      +42     
- Partials                                1567     1574       +7     

Files with missing lines	Coverage Δ
...src/main/kotlin/com/datadog/android/flags/Flags.kt	90.91% <100.00%> (ø)
...com/datadog/android/flags/internal/FlagsFeature.kt	85.07% <100.00%> (+0.46%)	⬆️
...in/kotlin/com/datadog/android/flags/FlagsClient.kt	36.67% <33.33%> (+0.14%)	⬆️
...tadog/android/flags/internal/DatadogFlagsClient.kt	88.83% <67.86%> (-3.76%)	⬇️
...tadog/android/flags/internal/EvaluationsFeature.kt	18.87% <2.44%> (-56.13%)	⬇️

... and 36 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[typotter]

Thanks. PTAL

[0xnm]

This operation is blocking and may be expensive (and block upstream). Since service doesn't change over SDK lifetime, it is better to read it once during the feature initialization.

[dd-oleksii]

🤔 You have suggested removing it from feature initialization before. Do you suggest reverting that or do something differently? wdyt about lazy init?

[0xnm]

I was suggesting reading it at the event write stage, this is not implemented. In this case it wouldn't be a blocking call, but an argument received at the withWriteContext callback.

And choosing between making such blocking call multiple times (at the onContextUpdate) vs once (at the feature initialization), the latter is a lighter approach.

[dd-oleksii]

Oh, I see, that makes sense. I guess one caveat is rum view name which is dynamic, so on write is too late as it might have changed. We need up-to-date context in processEvaluation() step

[0xnm]

so on write is too late as it might have changed

SDK handles this case. When withWriteContext is called, it is processed on a single thread for the whole SDK, which guarantees sequential processing and also DatadogContext is captured at the moment of the call (it is immutable data class).

This means that if evaluation flow opens withWriteContext as early as possible, and even if there is a time-arranged sequence of client calls (may be done from different threads, so actions may happen in parallel) like startView(A) -> evaluation -> startView(B), evaluation is guaranteed to receive a context at the time once startView(A) finished its processing and it won't be affected by the startView(B) context change.

But I guess since for the evaluation there is an aggregation, and write happens not the moment event is captured, the flow can be different. If write isn't not necessary there is a withContext callback (but there is no callback which would provide only WriteScope though, although it is not a big deal).

[dd-oleksii]

Cool. It looks like withContext is what we need here

[typotter]

We are only getting the ddContext once as we are using the currentContext.service and falling through to sdkCore.getDatadogContext() only when the value is null. Also, this first call to onContextUpdate will happen when the Feature is registered so it's not part of a regular queue of onContextUpdate calls (when the context actually is updated). It is, for all intents and purposes, tied into the initialization lifecycle already.