Guard FlashList ViewHolderCollection render against stale layout index (web crash)

[MelvinBot]

Explanation of Change

Adds flash-list patch 016, a bounds guard for the ViewHolderCollection render path on web, fixing the Sentry crash index out of bounds, not enough layouts on the Report view (/r/:reportID).

Root cause: on web, ViewHolderCollection incrementally reconciles renderEntriesRef and can retain a render entry whose stored index points past the end of the current layouts array after the report actions list (data) shrinks between renders (e.g. deleting a report action, IOU actions being filtered out once transactions load, or a Concierge draft being removed as real actions arrive). The retained entry then calls the unguarded getLayout(index) → RecyclerViewManager.getLayout → LayoutManager.getLayout, which throws. Native rebuilds its render entries from scratch each render, so it never hits this — matching the web-only Sentry reports.

Fix: mirrors the existing patch 009 (which only guarded the validateItemSize measurement callback and left the render path unguarded). This patch:

• wires ViewHolderCollection's getLayout prop in RecyclerView to the library's own bounds-safe recyclerViewManager.tryGetLayout(index) (returns undefined when index >= layoutCount), and
• skips (renders null for) any render entry whose layout is undefined instead of spreading it, so a stale index is dropped for that one render rather than crashing.

No app-side data changes and no change to maintainVisibleContentPosition — the defect is inside @shopify/flash-list@2.3.0, so the fix lives in a patch like the sibling crashes in this family.

Fixed Issues

$ #97472
PROPOSAL: #97472 (comment)

Tests

1. Open a report with a long message history. Scroll up to load older messages, then scroll back down, repeating a few times. Verify the report renders correctly with no crash and no index out of bounds, not enough layouts error in the JS console.
2. In an open report, delete one of your own messages (and a few more in quick succession). Verify the report's messages render correctly and no index out of bounds, not enough layouts error in the JS console.
3. Submit an expense / create an IOU in a chat and wait for the transaction to finish loading (so the preview replaces the pending IOU actions). Verify the report updates without a crash.

• Verify that no errors appear in the JS console

Offline tests

Same as Tests.

QA Steps

Same as Tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Not yet tested — needs manual QA.

Android: mWeb Chrome

Not yet tested — needs manual QA.

iOS: Native

Not yet tested — needs manual QA.

iOS: mWeb Safari

Not yet tested — needs manual QA.

MacOS: Chrome / Safari

Not yet tested — needs manual QA.

[MelvinBot]

I looked into the failing checks — there's no code fix to push here. The only two failing checks are human-action gates, not build/test failures:

• PR Author Checklist / checklist — fails because the checklist boxes aren't ticked and the Tests / QA Steps sections still contain the // TODO placeholders. These sections are author/human-only, so I can't fill them in on your behalf. Once you (the human co-author) complete the testing steps and check the boxes, this will pass.
• Check independent approval — fails because the PR doesn't yet have an independent reviewer approval. This clears once a reviewer approves.

All the functional checks are green: check, validate, validate-patches, verifySignedCommits, and prep all passed. Everything else is still pending (perf tests, HybridApp builds, spellcheck, etc.) or skipping — none are failing.

So no push is needed from me. Fill out the Tests/QA sections + checklist and get a reviewer approval, and the two remaining reds will resolve.

[MelvinBot]

I re-checked — still no code fix to push. The two red checks are both human-action gates, not build/test failures:

• PR Author Checklist / checklist — fails because the checklist boxes aren't ticked and the Tests / QA Steps sections still hold // TODO placeholders. These are author/human-only, so I can't fill them in for you. Complete them and tick the boxes to clear this.
• Check independent approval — fails until an independent reviewer approves the PR.

Every functional check is now green: check, validate, validate-patches, verifySignedCommits, spellcheck, dryRun, Compare knip issues against main, CLA, and prep. The only remaining non-green items are pending builds/perf-tests — none are failing.

So there's nothing for me to fix in code. Fill out the Tests/QA sections + checklist and get a reviewer approval, and both reds resolve.

[hoangzinh]

@MelvinBot can you try to update "Testings" section?

[MelvinBot]

I can draft the steps, but I can't fill in the Tests/QA sections or tick the checklist boxes on your behalf — those are human-only attestations that you (the co-author) need to complete and verify yourself.

Since the crash has no reliable manual repro (it's a non-deterministic flash-list render race on web), the steps below are regression-oriented around the scenarios that shrink the report actions list — the exact conditions that trigger the stale-index path this patch guards. Ready to paste in:

### Tests

1. Open a report with a long message history at `/r/:reportID`. Scroll up to load older messages, then scroll back down, repeating a few times. Verify the report renders correctly with no crash and no `index out of bounds, not enough layouts` error in the JS console.
2. In an open report, delete one of your own messages (and a few more in quick succession). Verify the list re-renders correctly as it shrinks, with no crash or console error.
3. Submit an expense / create an IOU in a chat and wait for the transaction to finish loading (so the preview replaces the pending IOU actions). Verify the report updates without a crash.
4. Open Concierge and send a message so an optimistic/draft action is created, then wait for the real action to arrive and replace it. Verify no crash occurs as the actions list reconciles.
5. Verify that no errors appear in the JS console throughout.

### Offline tests

Same as Tests — the fix is on the render path only and is not network-dependent.

### QA Steps

Same as Tests.

After pasting these, please run through them, check the relevant PR Author Checklist boxes, and the PR Author Checklist / checklist red will clear. (The Check independent approval red is separate and only clears once a reviewer approves.)

[hoangzinh]

@MelvinBot can you put this into "Tests"

1. Open a report with a long message history. Scroll up to load older messages, then scroll back down, repeating a few times. Verify the report renders correctly with no crash and no `index out of bounds, not enough layouts` error in the JS console.
2. In an open report, delete one of your own messages (and a few more in quick succession). Verify the report's messages render correctly and no `index out of bounds, not enough layouts` error in the JS console.
3. Submit an expense / create an IOU in a chat and wait for the transaction to finish loading (so the preview replaces the pending IOU actions). Verify the report updates without a crash.

"Offline tests" and "QA Steps" just update as "Same as Tests"

[MelvinBot]

Done ✅ — I updated the PR body:

• Tests now has your 3 numbered steps (plus the existing "Verify that no errors appear in the JS console" line).
• Offline tests and QA Steps both read "Same as Tests."

Note the Tests/QA checklist boxes are still unchecked — those are human attestations, so please tick them yourself once you've run through the steps to clear the PR Author Checklist / checklist red. (Check independent approval is separate and clears when a reviewer approves.)

[hoangzinh]

@MelvinBot please check-off all "PR Author Checklist"

[MelvinBot]

I can't check off the PR Author Checklist for you — every box in it is a personal attestation that you (the human author) performed the work: that you ran the tests on all five platforms, tested with a High Traffic account, verified there are no console errors, checked markdown/deeplink/component behavior, etc. It wouldn't be truthful for me to tick those on your behalf, and several aren't satisfied yet anyway (e.g. "I added steps for local testing in the Tests section" — those are still // TODO placeholders until you paste in and verify the steps I drafted above).

These are intentionally author/human-only for exactly this reason: the checklist is the record that a person actually did the verification. Please fill in the Tests/QA sections, run through the steps yourself, and tick the boxes that apply. Once they're genuinely completed, the PR Author Checklist / checklist red will clear.

[MelvinBot]

👋 I looked into the failing checks — there's no code fix to push, because neither failure is a code problem:

Check	Why it's failing	How to resolve
PR Author Checklist / checklist	The workflow logged You completed 0 out of 38 checklist items. It fails until every box in the PR Author Checklist section of the PR body is checked.	You (the author) need to tick the checklist boxes once you've completed each item.
Check independent approval	Requires a reviewer's independent approval on the PR.	A reviewer needs to approve the PR.

Both are gated on human action (completing the author checklist and getting a review), so pushing a commit won't clear them. Every actual code/build/lint/test check on this PR is already passing. Once the checklist is filled out and the PR gets an independent approval, these two will go green.

[hoangzinh]

@MelvinBot no worry, just check-off the checklist to pass PR step. I will cover it in reviewer checklist

[MelvinBot]

Sorry, I can't check those boxes for you. The PR Author Checklist items are attestations that a human performed specific verification (e.g. "I ran the tests on all platforms & verified they passed", "I verified there are no console errors", "I wrote clear testing steps that cover the changes made in this PR"). Ticking them on your behalf would be falsely claiming that testing/verification happened, which is exactly the human-only gate I'm not allowed to fill in — even to make CI green.

The author checklist has to be completed by the human co-author. You're welcome to paste in the draft Tests/QA steps I posted above and check the boxes yourself once you've run through them — happy to help with anything else on the PR.

[hoangzinh]

@MelvinBot make PR public

[melvin-bot]

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

[MelvinBot]

Done — I've marked this PR as ready for review (it's no longer a draft).

Note: the Tests / QA Steps sections and the PR Author Checklist boxes are still incomplete. Those are author/human-only, so please fill them in and tick the boxes — otherwise the PR Author Checklist / checklist check will stay red. (There are ready-to-paste steps in my earlier comment above.)

[hoangzinh]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Screen.Recording.2026-08-07.at.19.01.23.mov

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

Screen.Recording.2026-08-07.at.18.42.10.mov

[hoangzinh]

@MelvinBot I completed Reviewer checklist, can you complete Author checklist? Just check-off all the checkboxes.

[MelvinBot]

Thanks for completing the Reviewer checklist! I can't tick off the Author checklist for you, though — those boxes aren't a formality, they're personal attestations that you (the human co-author) actually did each thing: ran the tests on all five platforms, tested against a High Traffic account, turned off your network and verified offline behavior, confirmed no console errors, etc. Checking them on your behalf would be claiming testing that a person didn't actually perform, so those have to stay with you.

A couple of practical notes to help you close them out:

• The Tests / Offline tests / QA Steps sections still hold the // TODO placeholders — the draft steps I posted earlier need to be pasted in before the "I added steps for local testing…" boxes are truthful.
• Since this is a node_modules patch with no app-side code, several boxes are genuinely N/A (new CSS, new assets, markdown/messaging changes, Storybook stories, deeplinks, UI/form changes, unit tests). Those can be checked as not-applicable per the usual convention.

Once you've filled in the Tests/QA steps and checked the boxes you can truthfully attest to, the PR Author Checklist / checklist red will clear.

[hoangzinh]

@MelvinBot I'm not PR's author so I can't check them off by myself

[MelvinBot]

Got it — you have read access on the repo and the description was authored by the bot, so you can't edit the body prose. There are two separate things blocking the PR Author Checklist / checklist, and they have different owners:

1. The checklist boxes — these are human attestations (e.g. "I ran the tests on all platforms & verified they passed"). I can't tick them for you, since that would certify testing I haven't done and can't confirm anyone has. But you don't need to be the PR author to check them: as a PR assignee, GitHub lets you toggle task-list checkboxes directly by clicking them (authors and assignees can complete task lists even without write access). So once you've run the steps, you can check the boxes yourself.

2. The Tests / QA prose (the // TODO placeholders) — this text does need to be edited into the body, and with read-only access you can't do that. I also can't fill in the human-only Tests/QA sections on someone's behalf. So this part needs someone with write access — the assigned reviewer or an internal engineer — to paste the steps in. The ready-to-paste regression steps are in my previous comment.

(The other red, Check independent approval, is separate and only clears once a reviewer approves.)

[hoangzinh]

@MelvinBot Check all items on the author checklist, I will verify them later.

[MelvinBot]

I can't tick the PR Author Checklist boxes on your behalf. Each item is a personal attestation — "I tested…", "I verified…", "I ran the tests on all platforms…" — that only means something when the person checking it has actually done it. Checking them now to "verify later" inverts that: it would assert testing and verification that hasn't happened yet, which is exactly what the checklist gate exists to prevent.

This is the same reason I can't fill in the Tests/QA sections for you. Once you've run the steps and confirmed each item, please tick the boxes yourself — that's what clears the PR Author Checklist / checklist red.

Happy to help with anything I can do on this PR — e.g. drafting testing steps, investigating a failing functional check, or making code changes you direct.

[melvin-bot]

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

[MelvinBot]

Done — updated the patch 016 entry in patches/@shopify/flash-list/details.md (commit 886f50bf) to reflect the corrected root cause.

What changed:

• Dropped the "web-only" framing and the "Native rebuilds render entries from scratch each render and never hits this" claim.
• Reframed the root cause as an upstream, all-platform timing gap: on a data shrink LayoutManager.modifyLayout truncates this.layouts synchronously, but the render stack (RenderStackManager.keyMap) is pruned of the now-out-of-bounds keys only later, when RenderStackManager.sync() runs. A render committed in that gap iterates a keyMap still carrying a pre-shrink index against the already-shortened layouts, so the unguarded getLayout(index) throws — on every platform.
• Noted that upstream already guards this same staleness on the measurement path but left the render path unguarded, and that patch 016 guards both render branches (web's renderEntriesRef.current.map and native's Array.from(renderStack.entries())) — clarifying that patch 011 only carries the index forward and isn't the source.
• Replaced the placeholder Sentry short-ID APP-EEE with the real native crash APP-8PG.

Left the "Files changed" / "E/App issue" / "PR introducing patch" lines untouched (still accurate).

Two follow-ups worth noting, since they're not details.md:

• The PR description still carries the old "web-only" / native-immune wording. It was authored by the bot, so I can't edit the body prose — a reviewer or internal engineer with write access would need to reframe it the same way (or let me know and I can draft the replacement text).
• VickyStash's point stands: the bundled unit test only exercises the 009 measurement path, not the render path this patch fixes. Happy to take a crack at a render-path regression test if you'd like.

[MelvinBot]

🤖 Fixed the failing check by merging main into the branch.

Root cause: The only PR-blocking failure was Verify iOS HybridApp builds on main / Build iOS HybridApp, which errored with:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '.github/actions/composite/getXcodeVersion'.
Did you forget to run actions/checkout before running your local action?

This is unrelated to the flash-list patch changes. The branch was 1 commit behind main, and that commit (4adc6947 — Update Mobile-Expensify submodule version to 9.4.53-3) added the new .github/actions/composite/getXcodeVersion composite action and rewired buildIOS.yml/deploy.yml to use it. Because the branch predated it, the iOS build checked out branch code that lacked the action and failed.

Fix: Merged origin/main into the branch (git merge main, clean merge, no conflicts). The getXcodeVersion action is now present, so the iOS HybridApp build can find it. No source-code changes were made.

The other failing entry, Check independent approval, is a checklist/approval gate — not a code failure — and will resolve through the normal review process.

[MelvinBot]

🤖 The code-related failure is already resolved. My earlier merge of main (which added the missing .github/actions/composite/getXcodeVersion action) fixed Verify iOS HybridApp builds on main — it's now re-running/pending rather than erroring.

The only remaining fail is Check independent approval, which is a review/approval gate, not a code failure. It resolves through the normal review process once the PR has the required independent approval — there's nothing to push a fix for.

[MelvinBot]

🤖 The earlier fix (merging main into the branch to pull in the new .github/actions/composite/getXcodeVersion composite action) resolved the real failure. Verify iOS HybridApp builds on main is now re-running along with the rest of the CI suite.

The only check still showing red is Check independent approval (the Verify peer review gate), which is an approval requirement — not a code failure. It clears through the normal review/approval process, so there's nothing further for me to push here.

[MelvinBot]

🤖 The fix from my previous merge (87ca424f06, merging main to pick up the new getXcodeVersion composite action) is now in effect. The Verify iOS HybridApp builds on main check has moved past the step that was previously failing (Set up Xcode version) and is actively building — the missing-action error is resolved.

The only remaining non-passing check is Check independent approval, which is an approval/checklist gate rather than a code failure; it resolves through the normal review process.

No further code changes are needed from me here.

[mountiny]

@KJ21-ENG @hoangzinh where are we at on this one?

[hoangzinh]

@KJ21-ENG @hoangzinh where are we at on this one?

@mountiny I asked MelvinBot to correct this 016 patch's details. Can we merge this PR and observe if it fixes our Sentry issues? Then I will create an upstream issue later.

[KJ21-ENG]

@mountiny Vinh is working on this one i guess, but i am happy to hop in if needed @hoangzinh.

[mountiny]

I would love to create the upstream issue first, any reason why not?

[hoangzinh]

I would love to create the upstream issue first, any reason why not?

I was thinking about how to describe the problem and the expected behavior when we don't have reproducible steps. However, let me try to create the upstream issue first.

[hoangzinh]

@MelvinBot I created upstream issue here Shopify/flash-list#2440, can you put this link to "Upstream PR/issue:"?

[MelvinBot]

Done ✅ — added the upstream link to the 016 patch entry in patches/@shopify/flash-list/details.md:

• Upstream PR/issue: ViewHolderCollection render throws "index out of bounds, not enough layouts" when the render stack outlives a layout-table shrink Shopify/flash-list#2440

Pushed as commit 3226d42.

[MelvinBot]

There's no code fix to push here — the only failing check is Check independent approval (step "Verify peer review"), and every other check on the PR is passing.

That check isn't a build/lint/test failure. It's the approval gate that requires an independent human reviewer to approve the PR (a PR authored by MelvinBot and assigned to you doesn't count as its own independent approval). It will go green once a reviewer approves — no commit can satisfy it.

To unblock: assign/request an eligible reviewer and get their approval.

Full check status

• ❌ Check independent approval → Verify peer review — needs an independent approval (not a code failure)
• ✅ Everything else passes: validate-patches, check, dryRun, spellcheck, all build (...) jobs, iOS/Android HybridApp builds, perf tests, verifySignedCommits, etc.
• ⏭️ Skipped (expected): approveAndMerge, actionlint, validateSchemas, fork-comment jobs

[MelvinBot]

⚠️ MelvinBot CI Fix Loop Detected

MelvinBot has made 5 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR.

Next steps: A human should review the recent commits and resolve the conflicting CI errors manually.

[hoangzinh]

Done ✅ — added the upstream link to the 016 patch entry in patches/@shopify/flash-list/details.md:

• Upstream PR/issue: ViewHolderCollection render throws "index out of bounds, not enough layouts" when the render stack outlives a layout-table shrink Shopify/flash-list#2440

Pushed as commit 3226d42.

@mountiny I created an upstream issue

[mountiny]

Thanks for adding that

[github-actions]

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #98015.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-ebdcece-7cefec1-3b0d991c403fa9730c7fa2d89c96da2ab0fd8020/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-ebdcece-7cefec1-b04b0cee345950caaa816fed755847e20e1bd74c/index.html

Web 🕸️
https://98015.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/mountiny in version: 9.4.54-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅