Add dynamic sampling to frame screenshots by huntie · Pull Request #56048 · facebook/react-native

huntie · 2026-03-10T23:34:50Z

Summary:
Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events.

Motivation

Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame screenshot loss.
Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads.

Algorithm

Uses encodingInProgress atomic flag with single encoding thread and lastFrameBuffer storage for tail-capture of the last frame before idling (to capture settled animation states):

Not encoding: Frame passes directly to encoder → emits with screenshot when done
Encoding busy: Frame stored in lastFrameBuffer for tail-capture → any replaced frame emits without screenshot
Encoding done: Clears flag early, then opportunistically encodes tail frame without blocking new frames
Failed captures: Emit without screenshot immediately

Result: Every frame emitted exactly once. Encoding adapts to device speed. Settled animation state guaranteed captured.

Remaining work

⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next).
⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to Tracing.stop.

Changelog: [Internal]

Differential Revision: D95987488

meta-codesync · 2026-03-10T23:34:57Z

@huntie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D95987488.

Summary: Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame visual snapshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. NOTE: ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). NOTE: ⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to `Tracing.stop`. Changelog: [Internal] Differential Revision: D95987488

Summary: Pull Request resolved: facebook#56048 Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame visual snapshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. NOTE: ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). NOTE: ⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to `Tracing.stop`. Changelog: [Internal] Differential Revision: D95987488

Summary: Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame visual snapshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. NOTE: ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). **Dynamic throttling algorithm** - Use a single `lastFrameBuffer` to store the most recently captured frame (bitmap + metadata) - Use a serial background thread (single-thread executor) for all encoding work - Use an atomic `encodingInProgress` flag to track encoding state - Always capture screenshots to `lastFrameBuffer` on every frame (even during encoding), replacing any previous waiting frame - When not encoding: start encoding the captured frame - When encoding finishes: loop back and check if buffer was refilled, encode that frame if present - Always emit frame timing events immediately (without screenshot) This ensures we don't queue up excessive encoding work while maintaining continuous frame timing data and guaranteeing the final settled state of animations is captured (tail-capture), minimizing the performance impact of recording on the device. NOTE: ⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to `Tracing.stop`. Changelog: [Internal] Differential Revision: D95987488

Summary: Pull Request resolved: facebook#56048 Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame visual snapshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. NOTE: ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). **Dynamic throttling algorithm** - Use a single `lastFrameBuffer` to store the most recently captured frame (bitmap + metadata) - Use a serial background thread (single-thread executor) for all encoding work - Use an atomic `encodingInProgress` flag to track encoding state - Always capture screenshots to `lastFrameBuffer` on every frame (even during encoding), replacing any previous waiting frame - When not encoding: start encoding the captured frame - When encoding finishes: loop back and check if buffer was refilled, encode that frame if present - Always emit frame timing events immediately (without screenshot) This ensures we don't queue up excessive encoding work while maintaining continuous frame timing data and guaranteeing the final settled state of animations is captured (tail-capture), minimizing the performance impact of recording on the device. NOTE: ⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to `Tracing.stop`. Changelog: [Internal] Differential Revision: D95987488

Summary: Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame screenshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. **Algorithm** Uses `encodingInProgress` atomic flag with single-background-thread encoder and `lastFrameBuffer` for tail-capture: - **Not encoding:** Frame passes directly to encoder → emits with screenshot when done - **Encoding busy:** Frame stored in `lastFrameBuffer` for tail-capture → any replaced frame emits without screenshot - **Encoding done:** Clears flag early, then opportunistically encodes tail frame without blocking new frames - **Failed captures:** Emit without screenshot immediately Result: Every frame emitted exactly once. Encoding adapts to device speed. Settled animation state guaranteed captured. **Remaining work** - ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). - ⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to `Tracing.stop`. Changelog: [Internal] Differential Revision: D95987488

Summary: Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame screenshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. **Algorithm** Uses `encodingInProgress` atomic flag with single encoding thread and `lastFrameBuffer` storage for tail-capture of the last frame before idling (to capture settled animation states): - **Not encoding:** Frame passes directly to encoder → emits with screenshot when done - **Encoding busy:** Frame stored in `lastFrameBuffer` for tail-capture → any replaced frame emits without screenshot - **Encoding done:** Clears flag early, then opportunistically encodes tail frame without blocking new frames - **Failed captures:** Emit without screenshot immediately Result: Every frame emitted exactly once. Encoding adapts to device speed. Settled animation state guaranteed captured. **Remaining work** - ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). - ⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to `Tracing.stop`. Changelog: [Internal] Differential Revision: D95987488

Summary: Pull Request resolved: facebook#56048 Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame visual snapshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. NOTE: ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). **Algorithm** Uses `encodingInProgress` atomic flag with single-background-thread encoder and `lastFrameBuffer` for tail-capture: - **Not encoding:** Frame passes directly to encoder → emits with screenshot when done - **Encoding busy:** Frame stored in `lastFrameBuffer` for tail-capture → any replaced frame emits without screenshot - **Encoding done:** Clears flag early, then opportunistically encodes tail frame without blocking new frames - **Failed captures:** Emit without screenshot immediately Result: Every frame emitted exactly once. Encoding adapts to device speed. Settled animation state guaranteed captured. NOTE: ⚠️ We do still typically lose a small region of pending frames at the end of a trace, but this is now more reasonable. A further fix (likely unnecessary) is to add lifecycle methods to await frame processing before responding to `Tracing.stop`. Changelog: [Internal] Differential Revision: D95987488

Summary: Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame screenshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. **Algorithm** Uses `encodingInProgress` atomic flag with single encoding thread and `lastFrameBuffer` storage for tail-capture of the last frame before idling (to capture settled animation states): - **Not encoding:** Frame passes directly to encoder → emits with screenshot when done - **Encoding busy:** Frame stored in `lastFrameBuffer` for tail-capture → any replaced frame emits without screenshot - **Encoding done:** Clears flag early, then opportunistically encodes tail frame without blocking new frames - **Failed captures:** Emit without screenshot immediately Result: Every frame emitted exactly once. Encoding adapts to device speed. Settled animation state guaranteed captured. **Remaining work** - ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). Changelog: [Internal] Reviewed By: rubennorte Differential Revision: D95987488

meta-codesync · 2026-03-12T23:47:52Z

This pull request has been merged in d309cda.

react-native-bot · 2026-03-12T23:48:05Z

This pull request was successfully merged by @huntie in d309cda

^{When will my fix make it into a release? | How to file a pick request?}

Summary: Pull Request resolved: facebook#56048 Update Android frame screenshot processing to skip screenshot capture when encoding is already in progress — now limited to a single background thread — while always emitting frame timing events. **Motivation** 1. Prevents truncated trace data on slower devices (e.g. missing screenshots for the last 1/3 of the trace), with the tradeoff of some intermediate frame screenshot loss. 2. Reduces total recording overhead by freeing up device threads - prevents excessive encoding work from blocking or slowing down the UI and other app threads. **Algorithm** Uses `encodingInProgress` atomic flag with single encoding thread and `lastFrameBuffer` storage for tail-capture of the last frame before idling (to capture settled animation states): - **Not encoding:** Frame passes directly to encoder → emits with screenshot when done - **Encoding busy:** Frame stored in `lastFrameBuffer` for tail-capture → any replaced frame emits without screenshot - **Encoding done:** Clears flag early, then opportunistically encodes tail frame without blocking new frames - **Failed captures:** Emit without screenshot immediately Result: Every frame emitted exactly once. Encoding adapts to device speed. Settled animation state guaranteed captured. **Remaining work** - ⚠️ This still does not yet solve crashes (OkHttp network chunk size overflow) for heavy frame data at a high FPS on fast devices (coming next). Changelog: [Internal] Reviewed By: rubennorte Differential Revision: D95987488 fbshipit-source-id: cda5758e3091edd227d3838638ba157dbcea52d8

Backports some CDP Performance features and stability improvements to `0.83-stable`. This includes: - Remaining implementation of Frame Timings and screenshot capture in performance traces (Android) - New support for Frame Timings and screenshot capture on iOS - Optimisations to trace chunk generation, memory usage during performance recording - `Page.captureScreenshot` (Android, iOS) All features remain gated behind feature flags (`fuseboxFrameRecordingEnabled`, `fuseboxScreenshotCaptureEnabled`). **Commits applied** - Define TracingCategory enum (facebook#54377) bd6c6bf - Use TracingCategory in TraceEvent (facebook#54378) ce60f27 - Simple parser for serialized tracing categories (facebook#54379) 62275b6 - Propagate tracing categories to recording state (facebook#54380) 3841ef0 - Re-land "Revert D85999774: [rn][android] Add FrameTiming module" (facebook#54502) 85905ad - Add screenshot category (facebook#54537) 5d9cb80 - Define HostTargetTracingDelegate (facebook#54622) be0dae0 - Define TracingDelegate for Android Host (facebook#54628) a212e95 - Use new API for tracing state on Android (facebook#54629) 532d0be - Internalize TracingState interface (facebook#54631) 58ec261 - Move TracingState interfaces to inspector package (facebook#54632) 10d0d99 - Rename values of TracingState enum (facebook#54630) be94707 - FrameTiming module to subscribe to Inspector tracing lifecycle (facebook#54633) 04ee02b - Clarify HostTracingProfile and HostTraceRecordingState (facebook#54677) ec92f12 - Introduce TimeWindowedBuffer (facebook#54679) d6ee54f - Keep tracing time window on TraceRecordingState (facebook#54673) e651563 - Define FrameTimingSequence (facebook#54674) 5b7d92f - Define an endpoint on HostTarget to capture frame timings (facebook#54672) f469aa3 - Extract frame trace events construction logic (facebook#54675) 57973fa - Define serializers for frame timings as part of HostTargetTracingProfile (facebook#54681) 587d360 - Propagate Frames data through Host (facebook#54671) 26ff069 - Cleanup no longer used jni layer for frame timings (facebook#54678) 9ba4ce6 - Fix screenshot typo (facebook#54742) 52186a3 - Add optional screenshot argument to FrameTimingSequence (facebook#54743) 57c29fc - Frame screenshot event generation (facebook#54744) b447d26 - Frame screenshots capture implementation (facebook#54745) f3c9a8d - BeginDrawing: INTENDED_VSYNC_TIMESTAMP -> VSYNC_TIMESTAMP (facebook#54765) 9221772 - Add frames category (facebook#54768) 31a0c9a - Specify correct category for SetLayerTreeId event (facebook#54769) cd055e9 - Reduce the screenshots size (facebook#54800) e4a5a56 - Remove Commit from FrameTimingSequence (facebook#54779) 39f7703 - Fix potential bitmap leaks in FrameTimingsObserver (facebook#55652) 3918dd1 - Capture initial screenshot when starting frame timing trace (facebook#55720) 863f5c0 - Refactor FrameTimingsObserver for multi-activity support (facebook#55740) 8230f3b - Reorder FrameTimingsObserver methods (facebook#55743) f56b295 - Increase frame capture quality, apply scaling after DPI normalization (facebook#55731) e5f9f5f - Fix FrameTimingsObverver to initiate PixelCopy on main thread (facebook#55744) d552f2a - Fix bitmap reuse race condition in FrameTimingsObserver (facebook#55745) 3924768 - Fix trailing frame capture after recording ended (facebook#55704) 47684ca - Move base64Encode into react/utils (facebook#55873) 422770d - Move screenshot Base64 encoding to trace serialization (facebook#55803) dc4c36e - Restore inspector addPage listener callback (facebook#55925) 8c763fc - Add tracing helper functions for RNDT traces in C++ and Kotlin (facebook#55935) 4f3f536 - Introduce fuseboxFrameRecordingEnabled flag, gate existing code (facebook#55941) 1aa7a32 - Implement Performance frames and screenshots on iOS (facebook#56015) 64a1a10 - Add pixel diffing to RCTFrameTimingsObserver (facebook#56043) 9d231af - Add dynamic sampling to frame screenshots (facebook#56048) d309cda - Switch trace event chunks from event count to size based (facebook#56080) d3b33f5 - Increase trace screenshot scale factor to 1x (facebook#56079) 972a30d - Add Page.captureScreenshot CDP support (facebook#56307) 77332d2 - Fix data race on PerformanceObserver entry buffer (facebook#56352) 5eb1ca1 - [LOCAL] Remove stale frame event code from PerformanceTracer - [LOCAL] Update Podfile.lock

Backports some CDP Performance features and stability improvements to `0.83-stable`. This includes: - Remaining implementation of Frame Timings and screenshot capture in performance traces (Android) - New support for Frame Timings and screenshot capture on iOS - Optimisations to trace chunk generation, memory usage during performance recording - `Page.captureScreenshot` (Android, iOS) All features remain gated behind feature flags (`fuseboxFrameRecordingEnabled`, `fuseboxScreenshotCaptureEnabled`). **Commits applied** - Define TracingCategory enum (facebook#54377) bd6c6bf - Use TracingCategory in TraceEvent (facebook#54378) ce60f27 - Simple parser for serialized tracing categories (facebook#54379) 62275b6 - Propagate tracing categories to recording state (facebook#54380) 3841ef0 - Re-land "Revert D85999774: [rn][android] Add FrameTiming module" (facebook#54502) 85905ad - Add screenshot category (facebook#54537) 5d9cb80 - Define HostTargetTracingDelegate (facebook#54622) be0dae0 - Define TracingDelegate for Android Host (facebook#54628) a212e95 - Use new API for tracing state on Android (facebook#54629) 532d0be - Internalize TracingState interface (facebook#54631) 58ec261 - Move TracingState interfaces to inspector package (facebook#54632) 10d0d99 - Rename values of TracingState enum (facebook#54630) be94707 - FrameTiming module to subscribe to Inspector tracing lifecycle (facebook#54633) 04ee02b - Clarify HostTracingProfile and HostTraceRecordingState (facebook#54677) ec92f12 - Introduce TimeWindowedBuffer (facebook#54679) d6ee54f - Keep tracing time window on TraceRecordingState (facebook#54673) e651563 - Define FrameTimingSequence (facebook#54674) 5b7d92f - Define an endpoint on HostTarget to capture frame timings (facebook#54672) f469aa3 - Extract frame trace events construction logic (facebook#54675) 57973fa - Define serializers for frame timings as part of HostTargetTracingProfile (facebook#54681) 587d360 - Propagate Frames data through Host (facebook#54671) 26ff069 - Cleanup no longer used jni layer for frame timings (facebook#54678) 9ba4ce6 - Fix screenshot typo (facebook#54742) 52186a3 - Add optional screenshot argument to FrameTimingSequence (facebook#54743) 57c29fc - Frame screenshot event generation (facebook#54744) b447d26 - Frame screenshots capture implementation (facebook#54745) f3c9a8d - BeginDrawing: INTENDED_VSYNC_TIMESTAMP -> VSYNC_TIMESTAMP (facebook#54765) 9221772 - Add frames category (facebook#54768) 31a0c9a - Specify correct category for SetLayerTreeId event (facebook#54769) cd055e9 - Reduce the screenshots size (facebook#54800) e4a5a56 - Remove Commit from FrameTimingSequence (facebook#54779) 39f7703 - Fix potential bitmap leaks in FrameTimingsObserver (facebook#55652) 3918dd1 - Capture initial screenshot when starting frame timing trace (facebook#55720) 863f5c0 - Refactor FrameTimingsObserver for multi-activity support (facebook#55740) 8230f3b - Reorder FrameTimingsObserver methods (facebook#55743) f56b295 - Increase frame capture quality, apply scaling after DPI normalization (facebook#55731) e5f9f5f - Fix FrameTimingsObverver to initiate PixelCopy on main thread (facebook#55744) d552f2a - Fix bitmap reuse race condition in FrameTimingsObserver (facebook#55745) 3924768 - Fix trailing frame capture after recording ended (facebook#55704) 47684ca - Move base64Encode into react/utils (facebook#55873) 422770d - Move screenshot Base64 encoding to trace serialization (facebook#55803) dc4c36e - Restore inspector addPage listener callback (facebook#55925) 8c763fc - Add tracing helper functions for RNDT traces in C++ and Kotlin (facebook#55935) 4f3f536 - Introduce fuseboxFrameRecordingEnabled flag, gate existing code (facebook#55941) 1aa7a32 - Implement Performance frames and screenshots on iOS (facebook#56015) 64a1a10 - Add pixel diffing to RCTFrameTimingsObserver (facebook#56043) 9d231af - Add dynamic sampling to frame screenshots (facebook#56048) d309cda - Switch trace event chunks from event count to size based (facebook#56080) d3b33f5 - Increase trace screenshot scale factor to 1x (facebook#56079) 972a30d - Add Page.captureScreenshot CDP support (facebook#56307) 77332d2 - Fix data race on PerformanceObserver entry buffer (facebook#56352) 5eb1ca1 - Add dynamic sampling to frame screenshots (facebook#56135) e0d1e29 - Increase trace screenshot scale factor to 1x (facebook#56136) 90e02fa - Add missing debugger define for React-RuntimeApple (facebook#56397) - [LOCAL] Remove stale frame event code from PerformanceTracer - [LOCAL] Update Podfile.lock

meta-cla bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Mar 10, 2026

meta-codesync bot added fb-exported meta-exported labels Mar 10, 2026

facebook-github-bot added p: Facebook Partner: Facebook Partner labels Mar 10, 2026

huntie force-pushed the export-D95987488 branch from 9ff647c to 303d30b Compare March 11, 2026 22:27

huntie force-pushed the export-D95987488 branch from 303d30b to 553a459 Compare March 11, 2026 22:33

huntie force-pushed the export-D95987488 branch from 553a459 to f2155ae Compare March 11, 2026 22:58

huntie force-pushed the export-D95987488 branch from f2155ae to 57fe50b Compare March 11, 2026 23:05

huntie force-pushed the export-D95987488 branch from 57fe50b to 3a23a1e Compare March 12, 2026 20:56

meta-codesync bot closed this in d309cda Mar 12, 2026

facebook-github-tools bot added the Merged This PR has been merged. label Mar 12, 2026

huntie deleted the export-D95987488 branch March 18, 2026 10:37

huntie mentioned this pull request Apr 8, 2026

[0.83] Backport performance debugging improvements #56372

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add dynamic sampling to frame screenshots#56048

Add dynamic sampling to frame screenshots#56048
huntie wants to merge 1 commit intofacebook:mainfrom
huntie:export-D95987488

huntie commented Mar 10, 2026 •

edited

Loading

Uh oh!

meta-codesync bot commented Mar 10, 2026

Uh oh!

meta-codesync bot commented Mar 12, 2026

Uh oh!

react-native-bot commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

huntie commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

meta-codesync bot commented Mar 10, 2026

Uh oh!

meta-codesync bot commented Mar 12, 2026

Uh oh!

react-native-bot commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

huntie commented Mar 10, 2026 •

edited

Loading