Restore workspace list scroll position after navigation by MelvinBot · Pull Request #86158 · Expensify/App

MelvinBot · 2026-03-24T02:10:23Z

Explanation of Change

When navigating away from the Workspaces list and returning (e.g., tapping a workspace, then swiping back), the scroll position resets to the top. A previous fix (PR #77313) addressed this by integrating with ScrollOffsetContext but was reverted because it set initialNumToRender={data.length}, which rendered all items on mount and caused a multi-second JS thread block for accounts with 5K+ workspaces.

This PR re-applies the scroll position restoration approach using useLayoutEffect (for flicker-free restoration before paint) while fixing the performance issue. Instead of rendering all items, initialNumToRender is now dynamically calculated based on the saved scroll offset divided by an estimated row height (~88px), plus a small viewport buffer. For a user scrolled 3000px deep, this renders ~44 items — far less than the 5,000+ that caused the regression.

Changes:

WorkspacesListPage.tsx: Added ScrollOffsetContext integration with onScroll to save position, useLayoutEffect to restore it, and a smart initialNumToRender calculation
ScrollOffsetContextProvider.tsx: Include SCREENS.WORKSPACES_LIST in the route filter so saved scroll offsets survive navigation state cleanup

Fixed Issues

$ #76271

Tests

Log in to the App
Navigate to the Workspaces tab
Scroll down in the workspace list (ensure there are enough workspaces/domains to scroll)
Tap on any workspace to enter it
Navigate back (swipe back or press back button)
Verify the scroll position is restored to where you were before navigating away (should NOT jump to top)
Repeat steps 3-6 with a domain item instead of a workspace

Verify that no errors appear in the JS console

Offline tests

Log in and navigate to the Workspaces tab
Scroll down and note position
Go offline
Tap on a workspace and navigate back
Verify scroll position is preserved (the offset is saved in memory, not network-dependent)

QA Steps

Log in to the App with an account that has multiple workspaces
Navigate to the Workspaces tab
Scroll down to the bottom (to the Domains section)
Tap on any domain or workspace
Swipe back / press back button
Verify the app retains the previous scroll position after swiping back
If possible, test with a high-traffic account (many workspaces) to verify no performance degradation

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Web: Chrome

Tested via automated browser testing. Scroll position was set to 200px, navigated into a workspace, navigated back — scroll position was preserved at 200px (both via in-app back button and browser back navigation).

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Integrate WorkspacesListPage with ScrollOffsetContext to save and restore scroll position when navigating to/from workspace or domain pages. Uses useLayoutEffect to restore position before first paint, and dynamically calculates initialNumToRender based on the saved offset and estimated row height instead of data.length to avoid the performance regression that caused the previous fix (PR #77313) to be reverted. Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T02:10:32Z

I created this PR from an upstream branch since I don't have push access to your fork.

To take ownership of this branch and be able to push updates, run:

git remote add upstream https://github.com/Expensify/App.git
git fetch upstream claude-workspaceScrollPositionRestore
git checkout -b claude-workspaceScrollPositionRestore upstream/claude-workspaceScrollPositionRestore
git push -u origin claude-workspaceScrollPositionRestore

Then you can close this PR and open a new one from your fork.

Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T02:12:39Z

Fixed the failing Prettier check: ran prettier on WorkspacesListPage.tsx to format the initialNumToRender prop expression onto a single line.

rojiphil · 2026-03-24T02:16:04Z

@MelvinBot Implement the refined proposal

codecov · 2026-03-24T02:20:26Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/components/ScrollOffsetContextProvider.tsx	`62.22% <71.42%> (+4.32%)`	⬆️
src/pages/workspace/WorkspacesListPage.tsx	`59.14% <55.55%> (-13.53%)`	⬇️
... and 51 files with indirect coverage changes

Use onLayout to dynamically measure the actual workspace row height, with layout-aware fallback estimates for narrow (100px) and wide (88px) layouts. Compute initialNumToRender from the saved scroll offset and measured/estimated item height plus a viewport buffer, avoiding the performance regression from rendering all items. Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T02:24:45Z

Implemented the refined proposal. Here's what changed:

1. Dynamic row height measurement (primary source): Added a measuredItemHeight ref and an onLayout callback on a wrapper View around each workspace item in getWorkspaceMenuItem. The first item's height is captured and reused — this naturally adapts to narrow vs wide layouts without hardcoding.

2. Layout-aware fallback estimates: Replaced the single ESTIMATED_WORKSPACE_ROW_HEIGHT = 88 constant with two layout-specific fallbacks:

ESTIMATED_ITEM_HEIGHT_WIDE = 88px (avatar 40 + padding 40 + margin 8)
ESTIMATED_ITEM_HEIGHT_NARROW = 100px (avatar 40 + padding 40 + internal margin 12 + margin 8)

3. Smarter initialNumToRender calculation: Now computes the count using:

Measured height (when available from a previous render) as the primary source
Layout-aware estimated height as fallback
A viewport buffer (windowHeight / itemHeight) instead of the previous hardcoded +10

For a user scrolled to 3000px in narrow layout: ceil(3000/100) + ceil(900/100) = 39 items — far less than the 5K+ that caused the original revert.

rojiphil · 2026-03-24T02:35:36Z

@MelvinBot For Layout-aware fallback estimates, let us use style constants(e.g. variables.avatarSizeNormal) to arrive at the estimate instead of hardcoding to a constant value (i.e. 88)

Replace hardcoded height values with style constants from variables.ts (avatarSizeNormal, spacing2) and clearly-named local constants for the spacing values that cannot be imported at module level (p5 padding, mb3 margin). Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T02:42:01Z

Updated the fallback height estimates to use style constants instead of hardcoded values:

const WORKSPACE_ROW_PADDING = 20; // styles.p5 padding per side
const WORKSPACE_ROW_NARROW_MARGIN = 12; // styles.mb3 internal margin in narrow layout
const ESTIMATED_ITEM_HEIGHT_WIDE = variables.avatarSizeNormal + WORKSPACE_ROW_PADDING * 2 + variables.spacing2;
const ESTIMATED_ITEM_HEIGHT_NARROW = variables.avatarSizeNormal + WORKSPACE_ROW_PADDING * 2 + WORKSPACE_ROW_NARROW_MARGIN + variables.spacing2;

variables.avatarSizeNormal (40) — avatar size
variables.spacing2 (8) — styles.mb2 bottom margin on the OfflineWithFeedback wrapper
WORKSPACE_ROW_PADDING (20) and WORKSPACE_ROW_NARROW_MARGIN (12) — local constants for styles.p5 and styles.mb3 respectively, since @styles/utils/spacing cannot be imported directly (restricted by ESLint rule no-restricted-imports)

rojiphil · 2026-03-24T02:46:48Z

const WORKSPACE_ROW_PADDING = 20; // styles.p5 padding per side
const WORKSPACE_ROW_NARROW_MARGIN = 12; // styles.mb3 internal margin in narrow layout

@MelvinBot Avoid hardcoding for the above as well

…dding/margin Add spacing3 (12) and spacing5 (20) to style variables, following the existing spacing2 (8) pattern, and use them in the estimated workspace row height calculation to avoid hardcoded magic numbers. Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T02:49:57Z

Added spacing3: 12 and spacing5: 20 to variables.ts (following the existing spacing2: 8 pattern) and replaced the hardcoded constants:

const ESTIMATED_ITEM_HEIGHT_WIDE = variables.avatarSizeNormal + variables.spacing5 * 2 + variables.spacing2;
const ESTIMATED_ITEM_HEIGHT_NARROW = variables.avatarSizeNormal + variables.spacing5 * 2 + variables.spacing3 + variables.spacing2;

No more hardcoded values — everything derives from style variables now.

rojiphil · 2026-03-24T03:11:06Z

variables.spacing2 (8) — styles.mb2 bottom margin on the OfflineWithFeedback wrapper

@MelvinBot Instead of using generic spacing2, let us use the pattern of extracting the values from styles itself so that we know what it represents. Something like this:

const rowSpacing = (styles.mb2 as {marginBottom?: number})?.marginBottom ?? 0;

Replace variables.spacing2/spacing3/spacing5 with values extracted from the actual styles (styles.mb2, styles.p5, styles.mb3) so the height computation clearly reflects which styles it derives from. Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T03:14:39Z

Updated — now extracting spacing values from styles instead of using generic variables.spacing*:

const rowMarginBottom = (styles.mb2 as StyleNumericValue<'marginBottom'>)?.marginBottom ?? 0;
const rowPaddingVertical = (styles.p5 as StyleNumericValue<'padding'>)?.padding ?? 0;
const narrowInternalMargin = (styles.mb3 as StyleNumericValue<'marginBottom'>)?.marginBottom ?? 0;
const estimatedItemHeightWide = variables.avatarSizeNormal + rowPaddingVertical * 2 + rowMarginBottom;
const estimatedItemHeightNarrow = variables.avatarSizeNormal + rowPaddingVertical * 2 + narrowInternalMargin + rowMarginBottom;

Each variable name now clearly represents which style it derives from (rowMarginBottom from styles.mb2, rowPaddingVertical from styles.p5, etc.). Kept variables.avatarSizeNormal since there's no direct style to extract it from — it's a design token used by the Avatar component.

rojiphil

@MelvinBot Please address these review comments.

rojiphil · 2026-03-24T04:26:49Z

src/pages/workspace/WorkspacesListPage.tsx

+        const fallbackHeight = shouldUseNarrowLayout ? estimatedItemHeightNarrow : estimatedItemHeightWide;
+        // eslint-disable-next-line react-hooks/refs -- Reading the measured height ref during render is intentional; the value is only an optimization hint for initialNumToRender and stale reads are acceptable.
+        const itemHeight = measuredItemHeight.current ?? fallbackHeight;
+        const viewportItems = Math.ceil(Dimensions.get('window').height / itemHeight);


Let's use useWindowDimensions hook here.

@/tmp/reply-2978910740.md

rojiphil · 2026-03-24T04:27:42Z

src/pages/workspace/WorkspacesListPage.tsx

+    // available (from a previous render), otherwise falls back to a layout-aware estimate.
+    const savedScrollOffset = getScrollOffset(route) ?? 0;
+    const computedInitialNumToRender = (() => {
+        if (savedScrollOffset <= 0) {


Let's return undefined also when data.length is 0

@/tmp/reply-2978912770.md

rojiphil · 2026-03-24T04:31:21Z

src/pages/workspace/WorkspacesListPage.tsx

+        if (savedScrollOffset <= 0) {
+            return undefined;
+        }
+        const fallbackHeight = shouldUseNarrowLayout ? estimatedItemHeightNarrow : estimatedItemHeightWide;


Since this is fallback height, we can rely on a single height. Let us use wide height and remove the usage of narrow height.

@/tmp/reply-2978921217.md

rojiphil · 2026-03-24T04:32:30Z

src/styles/variables.ts

    inputComponentSizeNormal: 40,
    componentSizeLarge: 52,
    spacing2: 8,
+    spacing3: 12,


Remove spacing3 and spacing5 as they are redundant now.

@/tmp/reply-2978923760.md

rojiphil · 2026-03-24T04:47:05Z

src/pages/workspace/WorkspacesListPage.tsx

+                    if (measuredItemHeight.current) {
+                        return;
+                    }
+                    measuredItemHeight.current = e.nativeEvent.layout.height;


When the user comes back again to the workspace view with a preserved scrollOffset value, the measuredItemHeight would be empty. So, let's preserve the measured item height in ScrollOffsetContextProvider with support of additional method saveAverageItemLength

@/tmp/reply-2978963254.md

rojiphil · 2026-03-24T04:48:44Z

src/pages/workspace/WorkspacesListPage.tsx

+    );
+
+    const flatlistRef = useRef<FlatList | null>(null);
+    const measuredItemHeight = useRef<number | undefined>(undefined);


And, if available, let's retrieve the measured item height in ScrollOffsetContextProvider with support of additional method getAverageItemLength. Otherwise, let it be undefined

@/tmp/reply-2978967274.md

- Use useWindowDimensions hook instead of Dimensions.get('window') - Return undefined when data.length is 0 in initialNumToRender - Simplify to single fallback height (wide layout estimate only) - Remove spacing3 and spacing5 from variables.ts (no longer needed) - Persist measured item height in ScrollOffsetContextProvider via saveAverageItemLength/getAverageItemLength so it survives navigation - Extract fallback height values from styles instead of hardcoding Co-authored-by: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/issues/comments#get-an-issue-comment","status":"404"} <{"message":"Not Found","documentation_url":"https://docs.github.com/rest/issues/comments#get-an-issue-comment","status":"404"}@users.noreply.github.com>

rojiphil · 2026-03-24T05:41:02Z

@MelvinBot In ScrollOffsetContextProvider, we also need to delete averageItemLengthsRef.current in places where scrollOffsetsRef.current are deleted.

Delete averageItemLengthsRef.current entries in both the priority mode change effect and the cleanScrollOffsets helper, matching the existing cleanup of scrollOffsetsRef.current to prevent stale measured heights. Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T05:43:10Z

Added delete averageItemLengthsRef.current[key] in both places where scrollOffsetsRef.current entries are deleted:

The useEffect that clears offsets on priority mode change (for INBOX/SEARCH screens)
The cleanScrollOffsets helper used by cleanStaleScrollOffsets

This prevents stale measured heights from persisting after their associated scroll offsets are cleaned up.

rojiphil · 2026-03-24T06:09:57Z

src/pages/workspace/WorkspacesListPage.tsx

-                shouldShowErrorMessages={item.policyID !== policyIDToDelete}
-                shouldHideOnDelete={false}
+                onLayout={(e) => {
+                    if (getAverageItemLength(route)) {


@MelvinBot Let us return early if e.nativeEvent.layout.height is 0 as it does not make sense to set the average length.

Done — the onLayout callback now returns early when height <= 0, before updating either the local ref or the context.

Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

MelvinBot · 2026-03-24T06:12:05Z

Added an early return when e.nativeEvent.layout.height is 0 in the onLayout callback, so we skip saving a meaningless zero value as the average item length.

rojiphil · 2026-03-24T06:36:17Z

src/pages/workspace/WorkspacesListPage.tsx

-                shouldShowErrorMessages={item.policyID !== policyIDToDelete}
-                shouldHideOnDelete={false}
+                onLayout={(e) => {
+                    if (e.nativeEvent.layout.height === 0 || getAverageItemLength(route)) {


@MelvinBot Two comments here:

Let make the condition e.nativeEvent.layout.height <= 0 as that is safer

Also, we would run into problems if the measured height of item reduces as compared to the saved one. In this case, the reduced height would not get saved and this can cause scrolling issues. Let's save the measured height locally as a ref and also use it wherever needed. Also, we will allow updation only if local and saved one are not same.

Both addressed:

Changed guard to height <= 0 for safer handling

Added a local measuredItemHeight ref that always gets updated with the latest measured height from onLayout, syncs to ScrollOffsetContext only when the value differs from the saved one, and is used as the primary source in computedInitialNumToRender (falls back to context value, then to estimated height)

- Change onLayout condition to `height <= 0` for safer guard - Store measured height in a local ref and sync to ScrollOffsetContext only when values differ, ensuring height reductions are captured - Use local ref as primary source in initialNumToRender calculation Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

rojiphil

@MelvinBot Few more comments to address.

rojiphil · 2026-03-24T11:46:57Z

src/pages/workspace/WorkspacesListPage.tsx

+                    }
+                    measuredItemHeight.current = height;
+                    if (height !== getAverageItemLength(route)) {
+                        saveAverageItemLength(route, height);


Let us keep the measuredItemHeight and averageItemLength within ScrollOffsetContextProvider in sync by assigning height to measuredItemHeight.current here.

Done — moved the ref assignment inside the conditional block so both the local ref and context value are updated together, keeping them in sync.

rojiphil · 2026-03-24T11:48:05Z

src/pages/workspace/WorkspacesListPage.tsx

+    );
+
+    const flatlistRef = useRef<FlatList | null>(null);
+    const measuredItemHeight = useRef<number>(0);


Let us initialize measuredItemHeight with getAverageItemLength() value and keep them in sync.

Done — initialized measuredItemHeight ref with getAverageItemLength(route) ?? 0 so it has the saved value immediately on mount.

Initialize measuredItemHeight ref with the saved getAverageItemLength value so it's immediately available on component mount. Move the ref assignment inside the sync conditional so both the local ref and context value are always updated together. Co-authored-by: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/issues/comments#get-an-issue-comment","status":"404"} <{"message":"Not Found","documentation_url":"https://docs.github.com/rest/issues/comments#get-an-issue-comment","status":"404"}@users.noreply.github.com>

rojiphil · 2026-03-24T12:07:42Z

Awesome. Looks good now.

86158-web-chrome-002.mp4

rojiphil · 2026-03-25T11:21:33Z

@MelvinBot Please mark the PR as "Ready for review".

MelvinBot · 2026-03-25T11:22:58Z

Done — PR has been marked as Ready for review.

melvin-bot · 2026-03-25T11:22:59Z

@rojiphil 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]

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cc18547cd8

ℹ️ 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".

chatgpt-codex-connector · 2026-03-25T11:37:21Z

src/pages/workspace/WorkspacesListPage.tsx

+        const viewportItems = Math.ceil(windowHeight / itemHeight);
+        return Math.min(Math.ceil(savedScrollOffset / itemHeight) + viewportItems, data.length);


Cap initial render count for deep saved offsets

The initialNumToRender calculation still grows with savedScrollOffset and reaches data.length for users returning from very deep positions (for example, the domains section on high-traffic accounts with thousands of workspaces). In that case this mounts the entire list again, which reintroduces the same JS-thread stall this change is trying to avoid. Because the formula is ceil(offset / itemHeight) + viewportItems and then clamped with Math.min(..., data.length), sufficiently large offsets deterministically force a full render.

Useful? React with 👍 / 👎.

Agree. Let's fix this.
@MelvinBot Would using getItemLayout help here?

Yes, getItemLayout would be the right solution here. Here's why:

The problem: The current initialNumToRender = ceil(savedOffset / itemHeight) + viewportItems grows linearly with scroll depth. For a user scrolled to the domains section at the bottom of a 5K-workspace list, this approaches data.length and reintroduces the same JS-thread stall.

How getItemLayout + initialScrollIndex solves it: Instead of rendering all items from index 0 to N, FlatList uses getItemLayout to compute the exact offset of any item without rendering it, then renders only a small window (~10 items) around the initialScrollIndex. Performance is O(1) regardless of scroll depth — rendering 10 items whether the user scrolled to position 100 or position 5000.

The tradeoff: getItemLayout assumes predictable item heights. This list has mixed types:

Workspace rows: uniform height (the measured/estimated height we already track)

Domains header: different height

Domain rows: different height

Empty state components: different height

However, workspace rows dominate the list (the vast majority of items for high-traffic accounts), and the non-uniform items are at boundaries. Small inaccuracies from height mismatches are acceptable for scroll restoration — the user just needs to land near where they were, not pixel-perfect.

Implementation sketch:

const savedScrollIndex = savedScrollOffset > 0 ? Math.round(savedScrollOffset / itemHeight) : undefined; // On the FlatList: getItemLayout={(_, index) => ({ length: itemHeight, offset: itemHeight * index, index, })} initialScrollIndex={savedScrollIndex}

This eliminates initialNumToRender entirely for scroll restoration and caps rendering at a constant number of items regardless of scroll depth. We'd keep the onScroll save and ScrollOffsetContext integration as-is.

One caveat: ListHeaderComponent adds content above the list items that getItemLayout doesn't account for by default. We'd need to either include the header height in the offset calculation, or convert the header into the first item in the data array so getItemLayout covers it.

Want me to implement this approach?

MelvinBot assigned rojiphil Mar 24, 2026

MelvinBot requested a review from a team March 24, 2026 02:10

MelvinBot mentioned this pull request Mar 24, 2026

[$250] Workspace - Workspace page auto scroll to top after opening a domain and swipe back #76271

Open

8 tasks

Fix: run prettier on WorkspacesListPage.tsx

56dc81b

Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

rojiphil reviewed Mar 24, 2026

View reviewed changes

Add early return for zero layout height in onLayout callback

3839940

Co-authored-by: Roji Philip <rojiphil@users.noreply.github.com>

rojiphil reviewed Mar 24, 2026

View reviewed changes

MelvinBot marked this pull request as ready for review March 25, 2026 11:22

MelvinBot requested a review from a team as a code owner March 25, 2026 11:22

melvin-bot bot requested review from rojiphil and trjExpensify and removed request for a team March 25, 2026 11:22

melvin-bot bot removed the request for review from a team March 25, 2026 11:22

chatgpt-codex-connector bot reviewed Mar 25, 2026

View reviewed changes

		const viewportItems = Math.ceil(windowHeight / itemHeight);
		return Math.min(Math.ceil(savedScrollOffset / itemHeight) + viewportItems, data.length);

Conversation

MelvinBot commented Mar 24, 2026

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

rojiphil commented Mar 24, 2026

Uh oh!

codecov bot commented Mar 24, 2026 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

rojiphil commented Mar 24, 2026

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

rojiphil commented Mar 24, 2026

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

rojiphil commented Mar 24, 2026

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

rojiphil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rojiphil commented Mar 24, 2026

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MelvinBot commented Mar 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rojiphil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Mar 24, 2026 •

edited by github-actions bot

Loading