Merge develop into timeseries - #3750
Merged
Merged
Conversation
…rash On the fatal-crash path, getWriteContextSync was called while holding synchronized(rootScope), inverting the lock-acquisition order of the normal-event path (context-thread → pipeline-thread → rootScope). This created a 3-way circular wait between the crashing thread, the context thread, and the RUM pipeline thread, causing an ANR and losing the crash RUM event. Fix: fetch the write context before acquiring the rootScope lock so the ordering matches the normal path. The lock is now only held for the fast in-memory operations (rootScope.handleEvent + updateFeatureContext). Also removes the two stale // TODO RUM-9852 comments, adds a regression test asserting getWriteContextSync is not called while the rootScope monitor is held, and fixes a pre-existing missing timeProvider stub in RumViewManagerScopeTest that was exposed by the new test shifting the Forge seed sequence.
…ribution Inject the crash task into the RUM pipeline queue via BlockingQueue.put() instead of calling synchronized(rootScope) directly on the crash thread. put() bypasses the IGNORE_NEWEST back-pressure drop policy so the crash task is never silently discarded. The crash thread waits on a CountDownLatch until the pipeline thread has processed the task, ensuring the I/O thread receives the write operation before the process terminates. InterruptedException from put() and await() is caught, logged, and the interrupted flag restored.
RUM-17619: Fix deadlock/ANR in DatadogRumMonitor.handleEvent on JVM crash
…m-bug-version RUM-17226: Prevent profiling on package versions producing empty profiles
…ted-clicks RUM-17139: Fix gesture target selection for elevated views
…ge-upload RUM-17995: Migrate coverage upload auth to dd-sts, drop codecov
The Cronet instrumentation never tagged requests with a UUID, so RUM resource events fell back to matching on a `method•url•contentLength•contentType` key. `startResource` and `waitForResourceTiming` each generated their own random UUID, while `addResourceTiming`/`stopResource` generated none, which meant no two events of the same request ever agreed on a `ResourceId`: * the stop event, having a null uuid, compared equal to *every* concurrent resource scope on the same URL, so the first request to finish stopped them all, each emitting a resource with its own start date but the finisher's `_dd.trace_id`/`span_id`; * `waitForResourceTiming` never armed the scope, because its uuid differed from the one the scope was keyed with. Since RUM events are timestamped at the call site and processed asynchronously, a stop delivered to the wrong scope can be handled before that scope's start, producing a negative duration that is clamped to 1 ns and an `android.request` span stitched into an unrelated trace. Tag the request info with a fresh UUID in `CronetUrlRequest.start()`, before any instrumentation reads it. This mirrors what the OkHttp integration does via `RequestTracingStateRegistry`, and `start()` is the right place for it: a Cronet `UrlRequest` can only be started once, and it precedes both the RUM start/wait events and the annotation carried to the `RequestFinishedInfo` listener. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…esource-id-uuid RUM-18106: Add `UUID` for each Cronet call
Fix flaky RumViewScopeTest heatmapData test
The precompute service sends a serialId on each flag. The SDK discarded the value. The exposure event now carries it as a top-level serial_id field. The exposures intake uses the serial ID to find the holdout that an allocation comes from. A holdout becomes a usual allocation before an SDK receives the flag configuration, so the exposure event records no holdout. The serial ID is the only link back to it. The value travels through four hops: the precompute response, the precomputed flag model, the datastore, and the exposure event. The datastore must keep the value, because the SDK reads the flag state from the disk after a cold start. The exposure cache now compares the serial ID in addition to the allocation key and the variant key. A configuration refresh can add a serial ID, or change it, while both keys stay the same, and the intake must receive the value. Serial IDs start at zero for each organization, so the code tests for presence and not for a true value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…t-overwrite RUM-16113: Prevent inactive views from overwriting last_view_event
Removed the commit-signing bullet from AGENTS.md entirely. GitHub's require-signatures-github ruleset already blocks merging unsigned commits into develop natively — the doc text added no real enforcement and only gave the Codex PR bot something unreliable to check (false positives on both a real PR and a validly-signed test commit, including one outright hallucinated claim that a signed commit had no signature). No ticket, no real change. Safe to close/delete.
…filing-quota-context-name Remove `dd-` prefix from profiling quota thread pool context name
Every Session Replay instrumented test paid an unconditional Thread.sleep(2000) in beforeActivityLaunched, guarding against Espresso launching a new activity while the previous one was still being removed (which makes WindowInspector.getGlobalWindowViews() report both windows and alters the recorder's snapshots). Across 28 SR test methods that is ~56s of pure sleep per suite run, paid even when no previous activity exists. Poll for the actual condition instead, reusing the existing ConditionWatcher from tools/unit: wait until no activity remains in a non-DESTROYED lifecycle stage, via ActivityLifecycleMonitorRegistry (public AndroidX Test API that works on minSdk 23, unlike WindowInspector which is API 29+). The 2000ms becomes an upper bound rather than a fixed cost, so the constant is renamed to ACTIVITY_TEARDOWN_TIMEOUT_MS. Two safety choices preserve existing behaviour: - on timeout the wait proceeds instead of failing, matching the old "sleep then carry on" semantics, so a slow-but-passing test cannot turn red; - waitForIdleSync() drains the main looper afterwards, since an activity being destroyed does not guarantee its window is already gone (removal is posted to the main thread) and the window is what the guard is actually about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…cp-calls-to-claude-config Add allowed tools/MCP calls to the Claude config
RUM-18161: Send the serial ID on exposure events Co-authored-by: danyal002 <danyal.khan@datadoghq.com>
…eplay-instrumented-tests Replace fixed pre-launch sleep in `SessionReplayTestRule` with a poll
…v-2-timeseries # Conflicts: # features/dd-sdk-android-rum/src/test/kotlin/com/datadog/android/rum/internal/domain/RumDataWriterTest.kt
🎉 All green!🧪 All tests passed 🔄 Datadog retried 1 test - 1 passed on retry 🎯 Code Coverage (details) 🔗 Commit SHA: f6fd6bd | Docs | View more details | Give us feedback! |
hamorillo
approved these changes
Aug 21, 2026
kikoveiga
approved these changes
Aug 21, 2026
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
9 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.
What does this PR do?
Merges
developintotimeseriesMotivation
Solving conflicts
Review checklist (to be filled by reviewers)