Merge release/3.12.0 into master#3638
Conversation
…us-sample-rate-api RUM-15189: Add setContinuousSampleRate API to ProfilingConfiguration
…s-profiling-250326
…s-profiling-250326
…-continuous-profiling-250326 Merge `develop` branch into `feature/continuous-profiling` branch
…aunch-duration RUM-15190: Extend app launch profiling duration for continuous merge
…event-to-profiling Send event to Profiling feature when RUM session is renewed
…us-profiling-scheduler RUM-15191: Implement ContinuousProfilingScheduler
…inuous-profiling RUM-15323: RUM sends ANR & LongTask events to Profiling Feature
…lback RUM-15307: Report failure through ProfilerCallback
…e-profiling-rum-context RUM-15334: Commonize ProfilingRumContext for TTID and Continuous Profiling
…ing-rum-event RUM-15334: Add id to RumAnrEvent and RumLongTaskEvent
…filing-cycle Fix continuous profiling back-to-back with app launch by inserting a cooldown window
…-to-scheduler RUM-15321: Continuous profiling writes are gated on pending RUM events
…s-profiling-030426
…s-profiling-030426
…-continuous-profiling-030426 Merge `develop` branch into `feature/continuous-profiling`
…ndicator RUM-15454: Add Profiler status in RUM debug widget
RUM-17216: Remove unused consts from LogsFeature
RUM-17182: Stablize MoveDataMigrationOperationTest under high CPU usage
…-hosts-patterns RUM-16668: Add wildcard host pattern matching to first-party tracing
This reverts commit aabefd7.
… published lib" This reverts commit ed1e44e.
…nsole-validation-tokens Revert "Add Play SDK console verification token to new modules"
Several Continuous Profiling minor bug fixes
RUM-16362: Fix interop wireframe positioning in Compose windows
Prepare the 3.12.0 release
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d2cae63546
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // so their reads fail and their profiles are dropped as perfetto_unreadable. | ||
| // Deletion ownership needs to move to a single coordinator (read-once-and-fan-out | ||
| // bytes, or reference-count across instances) before multi-instance is supported. | ||
| safeDelete(profilingResult.resultFilePath) |
There was a problem hiding this comment.
Preserve shared Perfetto files until all SDK instances read them
In apps that initialize more than one SDK instance, DdProfilingContentProvider starts a single Perfetto recording with all saved instance names, and PerfettoProfiler dispatches the same resultFilePath to each registered ProfilingFeature. With this delete in each writer, whichever instance writes first removes the file before the remaining instances can read it, so their profile uploads are dropped as unreadable. The deletion needs to be coordinated once per shared result rather than performed by every per-instance writer.
Useful? React with 👍 / 👎.
| runnable = { | ||
| val cooldownMs = jitter(CONTINUOUS_COOLDOWN_DURATION_MS) | ||
| logToUser { LOG_ACTIVE_WINDOW_ENDED.format(Locale.US, cooldownMs) } | ||
| scheduleCooldown(cooldownMs) |
There was a problem hiding this comment.
Clear active state when the profiling window ends
When a continuous profiling window reaches its scheduled duration, this callback moves the scheduler to cooldown but leaves isActive true until the Perfetto result callback arrives. During that callback delay, ProfilingFeature.isRecordingProfile() still accepts RUM long task/ANR/vital events, so events that happened after capture ended can be drained into the finished profile and corrupt its RUM metadata; clear the active flag at the active-window boundary before scheduling cooldown.
Useful? React with 👍 / 👎.
| - docker buildx build --tag $CI_IMAGE_DOCKER -f ./ci/Dockerfile.gitlab --push . | ||
| - METADATA_FILE=$(mktemp) | ||
| - docker buildx build --tag $CI_IMAGE_DOCKER -f ./ci/Dockerfile.gitlab --push --metadata-file ${METADATA_FILE} . | ||
| - ddsign sign $CI_IMAGE_DOCKER --docker-metadata-file ${METADATA_FILE} |
There was a problem hiding this comment.
Run ddsign from an image that contains it
In the ci-image job, this command runs in 486234852809.dkr.ecr.us-east-1.amazonaws.com/docker:24.0.4-jammy, while the only ddsign installation added in this change is copied into ci/Dockerfile.gitlab, i.e. the image being built for later jobs rather than the runner image executing this script. Unless that external Docker image already ships ddsign, the manual image-publish job will push the image and then fail with ddsign: command not found; install or invoke ddsign in the job image itself.
Useful? React with 👍 / 👎.
| val lastFatalAnrSent = sdkCore.lastFatalAnrSent | ||
| if (anrExitInfo.timestamp == lastFatalAnrSent) return@withWriteContext | ||
| if (lastFatalAnrSent != null && | ||
| abs(anrExitInfo.timestamp - lastFatalAnrSent) <= FATAL_ANR_DEDUP_TOLERANCE_MS |
There was a problem hiding this comment.
Avoid deduping distinct fatal ANRs by timestamp tolerance
Because this check now suppresses any ApplicationExitInfo within 10 seconds of the persisted marker, a recoverable ANR that was reported in-process can hide a different fatal ANR that happens shortly afterward: RumViewScope now writes the same marker for successful non-fatal ANRExceptions, and the next launch returns here before reading or writing the fatal ANR trace. The dedupe should distinguish the same ANR from a later fatal one instead of treating every nearby timestamp as already reported.
Useful? React with 👍 / 👎.
| if (hierarchyChanged) { | ||
| lastPublishedScreenName = context.viewUrl | ||
| lastPublishedEntries.clear() | ||
| lastPublishedEntries.putAll(context.entries) |
There was a problem hiding this comment.
Republish heatmap identifiers after RUM becomes available
When Session Replay starts before RUM and captures a snapshot before RUM registers, LazyHeatmapIdentifierRegistry.setHeatmapIdentifiers() is a no-op because there is no delegate yet. This line still records the snapshot as already published, so if the next traversals are identical after RUM registers, hierarchyChanged stays false and the real RUM registry never receives the identifiers; native tap heatmaps then miss permanent IDs until the view hierarchy changes. Avoid marking the snapshot as published unless the delegate accepted it, or buffer it for retry.
Useful? React with 👍 / 👎.
What does this PR do?
Merge release/3.12.0 into master
Review checklist (to be filled by reviewers)