Repository navigation
[No QA] Add flash, capture method and time since app start to the shutter-to-confirmation span - #104829
[No QA] Add flash, capture method and time since app start to the shutter-to-confirmation span#104829OlimpiaZurek wants to merge 7 commits into
Conversation
…tter-to-confirmation span
|
@MelvinBot review |
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Review: looks good, with no blocking issues. The logic is correct, the child span still gets the same attributes, and CI passes except for the approval check. I found one data-interpretation point and some PR housekeeping. 1. A missing 2. Nit: 3. PR housekeeping:
I didn't run an app test. The change only affects native code, and this run only has a web tester. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9fb27eef8a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (nativeAppStartTimeMs === undefined) { | ||
| return undefined; | ||
| } | ||
| return Math.round(Date.now() - nativeAppStartTimeMs); |
There was a problem hiding this comment.
If the device wall clock is corrected while the process remains alive (for example by automatic time synchronization or a manual clock change), subtracting the startup epoch from a fresh Date.now() can produce a negative or greatly inflated duration_since_native_app_startup_ms, corrupting the telemetry this change is intended to analyze. Anchor the accepted startup age to a monotonic clock such as performance.now() when setting it, then compute later elapsed values from that same clock.
Useful? React with 👍 / 👎.
OlimpiaZurek
changed the title
|
@DylanDylann Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 93a8afa07b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (appStartAgeAtSetupMs === undefined) { | ||
| return undefined; | ||
| } | ||
| return Math.round(appStartAgeAtSetupMs + performance.now() - performanceNowAtSetupMs); |
There was a problem hiding this comment.
On Android, when the app process survives while the device enters deep sleep between telemetry setup and the shutter tap, React Native's performance.now() clock does not advance through that sleep. The reported duration_since_native_app_startup_ms can therefore omit hours and classify a resumed, warm process as a scan immediately after cold launch, skewing the analysis this attribute is intended for; use a suspend-aware monotonic native clock or explicitly account for suspended elapsed time.
Useful? React with 👍 / 👎.
dylanexpensify
left a comment
dylanexpensify
left a comment
There was a problem hiding this comment.
Product input not required
| Log.warn('[Telemetry] Failed to read native app start time from NitroModule', {error}); | ||
| nativeAppStartTimeMs = undefined; | ||
| } | ||
| setNativeAppStartTime(nativeAppStartTimeMs); |
There was a problem hiding this comment.
duration_since_native_app_startup_ms reuses the 60s prewarm guard from the startup span. So the value is missing for every session where RN boots more than 60s after the native process starts, not only prewarmed iOS processes.
In HybridApp that happens a lot. RN setup only starts after OldDot hands off (OldDotToRNHandoff), so these sessions get no value:
- an OldDot user who switches to NewDot after a minute
- an Android process started in the background (e.g. by a push) and opened later
In those sessions the native process is old but JS/RN is cold. That's the case most likely to look like "slow right after launch". Dropping them, and lumping them in with NitroModule read failures, skews the p95-by-startup-age split this PR is meant to enable.
Suggestion: always record the setup clocks, and also report time since JS setup. Then set a second attribute (e.g. duration_since_js_start_ms) on ManualShutterToConfirmation next to the native one. With both, process old + RN cold can be told apart from "true cold" launch
Reviewer Checklist
Screenshots/Videos
|
|
@OlimpiaZurek Can you also fix the failed Reassure Performance Tests? |
Explanation of Change
ManualShutterToConfirmationonly carriesplatform. The flash and capture method are set on the childManualReceiptCapturespan, so splitting the parent's p95 by flash needs a join on trace ID. On Android, flash captures are about 4% of captures but they set the p95, so we need that split to be a simple query.This PR sets three attributes on the parent span when the shutter is pressed on native:
capture_method(photoorsnapshot) andflash_used, from the same values the child capture span already uses. The child span keeps them too.duration_since_native_app_startup_ms: how long the native process had been running when the scan started. We want to know whether slow confirmation mounts on low-end Android devices happen soon after a cold launch. The constant already existed but nothing used it.The native app start time is read once during telemetry setup. A new
nativeAppStartTimemodule keeps it so later spans can use it. When setup discards the start time as stale (prewarmed process), it stores nothing and the attribute is left out, so no span reports a duration of hours.flash_usedmeans the user turned flash on and the device has a flash. It does not tell us whether the flash fired.Fixed Issues
$ #104482
PROPOSAL:
Tests
Offline tests
QA Steps
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari