perf: defer the split-save API.write behind the destination layout by Abdukhamid000 · Pull Request #98012 · Expensify/App

Abdukhamid000 · 2026-08-06T22:34:15Z

Explanation of Change

updateSplitTransactions was the only IOU write-then-navigate flow that never deferred its API.write. API.write applies optimisticData synchronously, so the destination screen re-renders from the transaction, report and report-action collections the write touches while the Save press is still trying to paint. This flow reached for requestAnimationFrame on two of its four exit branches, which fires before the paint.

Three changes:

Defer the write behind a navigation barrier. API.writeWhenReady(command, params, onyxData, createTransitionBarrier('navigation')), gated on isFromSplitExpensesFlow. Per JakubKorytko on this PR, deferOrExecuteWrite is being migrated out and removed shortly, so this uses writeWhenReady instead - credit to annaweber830, whose proposal identified that primitive. The barrier is route agnostic, so no channel has to be reserved per exit branch and the Search branch needs no special casing. Outside the split-expenses flow there is no transition to wait on and the default barrier would stall the write ~2s, so those callers (e.g. useDeleteTransactions) keep writing immediately.
Drop three forward-only subscriptions on SplitExpensePage (folding in yusufdeveloper2903's proposal). REPORT_NAME_VALUE_PAIRS, SNAPSHOT and PERSONAL_DETAILS_LIST were each read with useOnyx and then used in exactly one place - forwarded to the save action. Nothing rendered from them, so every unrelated write to those collections re-rendered the page. They now go through the existing getAllReportNameValuePairs, getAllSnapshots and getAllPersonalDetails getters, all already backed by module-level caches in actions/IOU/index.ts, so no new Onyx subscription is added. Correction to an earlier version of this body: those getters do sit on plain Onyx.connect (src/libs/actions/IOU/index.ts:11,74), whose JSDoc reads This method will be deprecated soon. Please use Onyx.connectWithoutView() instead. This PR adds no new subscription of either kind, but it is not accurate to say the path carries no deprecation tag - it reuses existing subscriptions that do. Migrating those getters to connectWithoutView is out of scope here and belongs in its own PR.
Scan allTransactionsList once instead of twice per press (folding in dilshodmackbook-sketch's dedup). The two consumers disagree on how a missing expenseReportID should behave, so the guard moved onto the derived value rather than onto the scan, keeping both behaviours byte-identical.

Per the review notes, allTransactionsList and POLICY_TAGS are deliberately left alone - the former would lose Search-snapshot-only transactions, and getPolicyTags is slated for removal in #72721. No hash-scoped SNAPSHOT selector and no getAllTransactionViolations.

Every navigation decision is computed from params.allTransactionsList before any write, so deferring cannot change where the user lands. The emitted onyxData is unchanged.

Durability trade-off (answering ikevin127 and the Codex P2 bot, same concern from two angles) - resolved by @JakubKorytko. The cost is real and stated plainly: writeWhenReady does not reach prepareRequest until the barrier releases, so there is a window - bounded by SAFETY_TIMEOUT_MS, currently 5 * CONST.MAX_TRANSITION_DURATION_MS = 5000 ms, and in practice the length of one screen transition - in which a browser reload or a native hard kill drops the split with no error and no queued request. apiWrite persisted synchronously and had no such window.

I raised this against writeWhenReady's own caveat (critical writes (such as ones that move money) should not be deferred) and offered to revert to a synchronous API.write. Jakub, who wrote both the primitive and that caveat, ruled that the wording is the problem rather than this PR: SendMoney already defers its write today via deferOrExecuteWrite with the same risk shape, so "moves money" was never the line the codebase actually draws. The operative test is whether losing the write leaves something unrecoverable or hard to reconcile versus merely annoying to redo - a dropped split is the latter. He is tightening the wording in writeWhenReady.ts so this does not resurface on the next PR, and is fine keeping the deferral here.

Why it stands: the window is the transition the user is already watching, they cannot interact during it, and deferring a money-moving write is already the established pattern in this directory rather than a new precedent - on main today SendMoney.ts:557 (SEND_MONEY_ELSEWHERE / SEND_MONEY_WITH_WALLET), Split.ts:370 and :488, PerDiem.ts:1119 and :1217, and SendInvoice.ts:874 all defer via deferOrExecuteWrite. There is a flushOnBackground best-effort path for backgrounding, though the docs are explicit that it is not guaranteed.

Open item: the INP benefit is still not demonstrated, and my earlier attempt to size it measured the wrong thing twice over. The first measurements were withdrawn because the profiler recorded pointerdown rather than the interaction's longest event, under-reporting INP by roughly 8-10x. The replacement figure I quoted - API.write at 1.0 ms of a 6-17 ms interaction - is also not the cost this defers: as Jakub points out, write() itself is the cheap part, and what the barrier actually holds back is the optimistic Onyx update and the re-render it triggers, which is the work competing with the transition. That is the number worth having and I do not have it yet. The barrier measurement below confirms the mechanism engages; it does not show that INP improved. Sizing the optimistic-update and re-render cost is the remaining work, and it is not a blocker for this PR per the ruling above.

Barrier behaviour on the Search branch - confirmed. ikevin127 raised that the barrier waits for an upcoming navigation transition, so if navigateBackToLastSuperWideRHPScreen() does not register as a navigation-kind transition, this branch would fall back to writeWhenReady's safety timeout instead of releasing on the transition. Measured on an Android emulator (dev build, Android 15, arm64), saving a split from the Spend > Expenses list:

19:27:25.648  [API] Called API writeWhenReady - {"command":"Transaction_Split", ...}
19:27:26.748  [API] Called API write          - {"command":"Transaction_Split", ...}

The write was deferred 1.100 s and was released by the transition, not by a fallback:

no "... did not release the write" warning anywhere in the session, so it was not the SAFETY_TIMEOUT_MS (5 s) release;
no [TransitionTracker] waitForUpcomingTransition timed out before a transition started between those two lines, so it was not the MAX_TRANSITION_START_WAIT_MS (1 s) give-up either.

Barrier behaviour on web - measured, does not hit the safety timeout. ikevin127's open question was whether the 'navigation' barrier ever releases on web/desktop, or silently degrades to the 5 s SAFETY_TIMEOUT_MS. Measured on web (Chromium, local rsbuild dev server against staging), saving a selfDM split from the split-expenses flow:

Save press          t =   0 ms   (capture-phase click listener, in-page)
Transaction_Split   t = 245 ms   (patched window.fetch, same performance.now() clock)
SAFETY_TIMEOUT_MS   never reached (5000 ms = 5 * CONST.MAX_TRANSITION_DURATION_MS)

Both timestamps are taken inside the page in one clock, so no tooling round-trip is included. The barrier released on the real screen transition at 245 ms - roughly 20x below the fallback. This also covers the selfDM exit on web, one of the two branches raised in finding 5.

Scope of this measurement, stated plainly: one run, web/Chromium only, dev build. Desktop/Electron is not separately measured, though it shares the same @react-navigation/stack navigator that ScreenLayout.tsx:33 listens to (native uses native-stack). The default and Search exits on web are still unmeasured.

Structurally, ScreenLayout.tsx:33 is the only emitter of startTransition('navigation') in the codebase, driven by React Navigation's transitionStart/transitionEnd; web resolves that through @react-navigation/stack 7.8.5, which is why the barrier has a real transition to release on there.

So navigateBackToLastSuperWideRHPScreen() does register as a navigation transition and this branch releases on it. The practical consequence is worth a reviewer's eyes: the optimistic split rows land ~1.1 s after the Save press on this device, so there is a visible gap between the press and the split appearing at the destination. That is the intended trade-off of deferring rather than a defect, but it is a real behaviour change.

Two smaller behaviours confirmed on the same device while measuring: pressing Save with no edits issues no API call at all, and a split row left at 0.00 is blocked by Please enter a valid amount before continuing rather than being written.

Fixed Issues

$ #97802
PROPOSAL: #97802 (comment)

Tests

Open the Search (Spend) page and click an expense that is not already split
Click More -> Split
Adjust the split amounts (or leave the even split) and press Save
Verify you land back on the Search page and the expense now shows its split children
Repeat starting from a report: open a report -> open an expense -> More -> Split -> Save, and verify you land on the report with the split applied
Repeat for a self-DM tracked expense and verify you land on the self-DM report, with no "Not Found" flash
Reduce an existing split back to a single item and press Save (reverse split); verify the original expense is restored and you are not stranded on a "Not Found" page

Failure scenarios

With the network throttled to fail, perform a Save; verify the optimistic split is rolled back and the error is surfaced on the transaction rather than left applied
Press Save twice in quick succession; verify only one split is created and no duplicate rows appear on the destination
Start a Save and immediately navigate away before the destination finishes laying out; verify the write still executes (the channel's safety timeout covers a destination that never mounts) and the split is not lost

Automated coverage added in tests/actions/IOUTest/SplitTest.ts (split save deferred write):

saving through the split-expenses flow routes the write through writeWhenReady with a barrier
the same barrier-gated path is used when saving from the Search page, confirming the barrier is route agnostic
a direct updateSplitTransactions call outside the split-expenses flow is not deferred

Both suites mock writeWhenReady to run the write inline: no screen transition happens in a test, so the barrier would otherwise hold the write until its safety timeout and every optimistic-data assertion would fail. The barrier-gated path itself is asserted by the three tests above rather than mocked away.

Verified locally at the current head: SplitTest.ts, SplitSelfDMTest.ts, deferredLayoutWriteTest.ts, SplitReportTotalsTest.ts - 193 passed, 0 failed (4 suites). typecheck-tsgo clean, ESLint 0 errors on all changed files, react-compiler-compliance-check passes.

Verify that no errors appear in the JS console

Offline tests

Turn off your network connection
Perform the Save from Search, from a report, and from a self-DM tracked expense as in the Tests section
Verify the split still appears optimistically in each case and you land on the expected destination
Verify the Search page still highlights the newly created split rows while offline (the highlight is registered before the write and does not wait on it)
Restore the connection and verify the queued writes are sent and no rows are duplicated

QA Steps

Same as tests.

Verify that no errors appear in the JS console

PR Author Checklist

The unchecked boxes below are the per-platform screenshots and on-device runs still outstanding; they are tracked in the review thread rather than blocking on draft status. Nothing is checked that was not actually verified. Items phrased "If X ..." are checked where X does not apply and that was confirmed against the diff (no CSS, no assets, no copy, no UI change, no generic component, no Storybook stories, no message-composer code).

Screenshots/Videos

Android: Native

native.mov

Android: mWeb Chrome

android-nweb.mov

iOS: Native

ios-record-expensify.mov

iOS: mWeb Safari

nweb-expensify.mov

MacOS: Chrome / Safari

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

updateSplitTransactions is the only IOU write-then-navigate flow that never routed its API.write through deferOrExecuteWrite. API.write applies optimisticData synchronously, so the destination screen re-renders from the transaction/report/report-action collections the write touches while the press is still trying to paint. Collect the three apiWrite calls into one closure and hand it to deferOrExecuteWrite, gated on isFromSplitExpensesFlow so useDeleteTransactions and other callers are unaffected. Reserve the matching channel on each of the four exit branches before navigating (SEARCH on the Search branch, DISMISS_MODAL with the destination report ID on the report branches), and move updateSplitTransactions after the navigation call on the two branches that ran it first. Every navigation decision is computed from params.allTransactionsList before any write, so deferring cannot change where the user lands. onyxData is unchanged.

…ions REPORT_NAME_VALUE_PAIRS, SNAPSHOT and PERSONAL_DETAILS_LIST were each read by useOnyx and then used in exactly one place - forwarded to updateSplitTransactionsFromSplitExpensesFlow. Nothing rendered from them, so every unrelated write to those collections re-rendered the page. Read them at save time through the existing getAllReportNameValuePairs, getAllSnapshots and getAllPersonalDetails getters instead. All three are already backed by module-level caches in actions/IOU/index.ts, so this adds no new Onyx subscription, and none of them carries a deprecation tag. allTransactionsList and POLICY_TAGS are deliberately left alone: the former would lose Search-snapshot-only transactions, and getPolicyTags is slated for removal in Expensify#72721.

The expense-report transaction filter ran twice per press over the whole transaction collection - once for areAllExpenseReportTransactionsSplitChildren and again just to take .length for the last-transaction check. Hoist it to a single scan. The two consumers disagree on how a missing expenseReportID should behave, so the guard moves onto the derived value to keep both behaviours byte-identical rather than onto the scan.

Three tests in SplitTest.ts for the new behaviour: - saving from the Search page reserves the SEARCH channel and routes the write through deferOrExecuteWrite with shouldDeferForSearch: true - saving from a report defers without ever touching the SEARCH channel - a direct updateSplitTransactions call outside the split-expenses flow is not deferred, since there is no navigation to hide behind SplitSelfDMTest.ts needed the deferredLayoutWrite mock SplitTest.ts already uses. Without it the selfDM branch now parks its write on the DISMISS_MODAL channel and no destination screen mounts in a test to flush it, so three assertions on optimistic data failed. The mock runs the write inline; the deferral timing itself is covered by the tests above rather than mocked away.

JakubKorytko · 2026-08-07T10:21:04Z

Hi! I'm really happy to see you want to use my solution. That being said, please use API.writeWhenReady instead of deferOrExecuteWrite. The latter will be migrated and removed in the coming days, so please use the former to avoid conflicts.

github-actions · 2026-08-07T10:34:36Z

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

@JakubKorytko

@JakubKorytko asked for writeWhenReady on the PR: deferOrExecuteWrite is being migrated and removed in the coming days, so building on it now would only create a conflict. Credit to @annaweber830, whose proposal identified this primitive. The barrier is route agnostic, which simplifies the change considerably: - writeWhenReady(command, params, onyxData, createTransitionBarrier('navigation')) replaces the closure plus deferOrExecuteWrite - all four reserveDeferredWriteChannel calls are gone; a barrier needs no channel reserved ahead of navigating, so the Search branch no longer needs special casing - the two branches that were reordered are back to committing before they navigate, which is also what the barrier wants: it waits for an upcoming navigation transition, so it has to be registered before that navigation Still gated on isFromSplitExpensesFlow. Outside that flow there is no transition to wait on and the default barrier would stall the write for roughly 2s, so those callers keep writing immediately. Tests assert the barrier-gated path on both the report and Search branches, and that a direct updateSplitTransactions call is not deferred. Both suites mock writeWhenReady to run inline, since no screen transition happens in a test and the barrier would otherwise hold the write until its safety timeout.

Abdukhamid000 · 2026-08-10T14:48:20Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7220b84414

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

Resolved one conflict in SplitTransactionUpdate.ts: main added the CurrencyListActionsContextType import and this branch changed the @libs/API import to pull in createTransitionBarrier/writeWhenReady. Kept both. main also made getCurrencyDecimals a required param on BuildOptimisticIOUReportActionParams and UpdateSplitTransactionsParams, so the split-save tests added here now pass getCurrencyDecimalsLocal, matching the convention already used elsewhere in SplitTest.ts.

Abdukhamid000 · 2026-08-11T07:28:59Z

I have read the CLA Document and I hereby sign the CLA

Abdukhamid000 · 2026-08-11T07:45:46Z

recheck

melvin-bot · 2026-08-11T07:47:08Z

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

melvin-bot · 2026-08-11T07:47:12Z

@rlinoz 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: 260fe6631e

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

JmillsExpensify

No product review required.

rlinoz

Looking good, but I think we can improve the design here.

Also, can you please sign your commits 🙇

rlinoz · 2026-08-18T14:23:27Z

+ *
+ * Opting in is suite-wide, not per-flow: `jest.mock('@libs/API/writeWhenReady')` un-defers every caller in the
+ * suite. Today `SplitTransactionUpdate.ts` is the only production caller, but `deferOrExecuteWrite` is being
+ * migrated onto this module - once those flows land, this mock will silently un-defer them and no test will fail.


Suggested change

*

* Opting in is suite-wide, not per-flow: `jest.mock('@libs/API/writeWhenReady')` un-defers every caller in the

* suite. Today `SplitTransactionUpdate.ts` is the only production caller, but `deferOrExecuteWrite` is being

* migrated onto this module - once those flows land, this mock will silently un-defer them and no test will fail.

rlinoz · 2026-08-18T15:38:44Z

+            allReportNameValuePairsList: getAllReportNameValuePairs(),
+            allSnapshots: getAllSnapshots(),


Unfortunately I don't think we can use this, since we are in the process of deprecating Onyx.connect which this functions depend on (they should probably be deprecated or removed).

The real solution will depend on each case, but it is usually to call useOnyx with some selector.

For instance I think getAllReportNameValuePairs() is not needed, in the split flow it is only used here

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Line 399 in 6209581

const expenseReportNameValuePairs = allReportNameValuePairsList?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${expenseReport?.reportID}`];

and that only needs the rNVP for a specific reportID which we should be able to derive for the selector.

Agreed, and done locally — it goes out with the signed force-push, so it isn't on the branch yet.

SplitExpensePage already reads whole collections through useOnyx (:111, :112, plus useAllTransactions()), so the three getters follow the same pattern:

-import {getAllPersonalDetails, getAllReportNameValuePairs, getAllSnapshots} from '@libs/actions/IOU'; + const [allReportNameValuePairs] = useOnyx(ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS); + const [allSnapshots] = useOnyx(ONYXKEYS.COLLECTION.SNAPSHOT); + const [personalDetails] = useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST);

getAllReportNameValuePairs() / getAllSnapshots() / getAllPersonalDetails() are gone from this page entirely, so nothing here depends on Onyx.connect any more. Net +6/-4; lint, typecheck and React Compiler compliance pass, and the three split suites (SplitTest, SplitReportTotalsTest, TransactionTest) are green at 170 tests.

On narrowing them to per-key selectors — two of the three don't reduce cleanly, so I'd rather raise it than quietly ship something that breaks.

allReportNameValuePairsList has a second consumer. Besides SplitTransactionUpdate.ts:399 keyed on expenseReport?.reportID, there is :1375:

const reportNameValuePairs = allReportNameValuePairsList?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${splitTransaction?.reportID}`];

That runs per split transaction inside the undeleted-transactions loop, and splitTransaction is looked up out of allTransactionsList one line earlier at :1370 — so those reportIDs aren't known at render time. A selector narrowed to expenseReport.reportID would leave isArchivedReport(...) at :1378 reading undefined for every split.

allSnapshots is scanned wholesale on purpose. :1459, :1521 and :1727 each iterate Object.entries(allSnapshots), per the comment at :1448: "We scan allSnapshots instead of relying on currentSearchHash because the user may navigate…". There is no single key to select.

getAllPersonalDetails() reads ONYXKEYS.PERSONAL_DETAILS_LIST, a single key, so that one is a straight swap either way.

So: is whole-collection useOnyx acceptable here, matching allReports/allReportActions already in this file? Or would you rather have the selectors, with those two call sites reworked to feed them? Happy either way — the second is a meaningfully larger change to SplitTransactionUpdate, so I'd rather confirm the shape before writing it.

ikevin127 · 2026-08-19T00:07:39Z

Also, can you please sign your commits 🙇

@Abdukhamid000 For this you need to follow the guide on getting your commits signed here. This means that you will probably have to force-push again since all commits on a PR must be Verified (signed), otherwise PR cannot be merged.

@ikevin127 a question before I touch anything, since it runs into your earlier note.

verifySignedCommits is failing — all 11 commits on this branch are unsigned. The check has no allowlist, it fails if any commit in the PR is unverified, and signing a commit changes its SHA, so the only way to clear it is to amend all 11 and force push.

That is exactly what you asked me not to do on 2026-08-15 (CONTRIBUTING.md:200, never force push once review has started), which is why I would rather ask than assume.

Force-pushing again will be required in this case as to avoid closing and reopening the PR and losing all discussion / context, but note it for the future to not repeat - unless it would require closing / reopening PR and losing significant context (like this case).

…x.connect getters

Abdukhamid000 · 2026-08-19T05:21:29Z

@rlinoz — signed commits are pushed. All 12 commits on the branch now show as Verified, so Verify signed commits should be satisfied. The force-push was cleared by @ikevin127 for exactly this reason.

Two things:

1. The workflows need approving again. The push reset them — all 15 runs, including Verify signed commits itself, are sitting at action_required. Same ask as the first time 🙏

2. Both of your review comments are addressed. The writeWhenReady mock docblock paragraph is deleted, and SplitExpensePage no longer touches the Onyx.connect getters — getAllReportNameValuePairs(), getAllSnapshots() and getAllPersonalDetails() are gone, replaced with useOnyx reads alongside the allReports / allReportActions ones already in that file.

I left one question open in that thread: whether you want them narrowed to per-key selectors. Two of the three don't reduce cleanly — allReportNameValuePairsList has a second consumer at SplitTransactionUpdate.ts:1375 keyed on each splitTransaction?.reportID (not knowable at render time), and allSnapshots is scanned wholesale at three sites by design. Happy to do the selectors, but that means reworking those call sites, so I'd rather confirm the shape first.

Other than those two changes, the history rewrite was signature-only — the diff is byte-identical to what you reviewed.

codecov · 2026-08-19T22:04:26Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/libs/actions/IOU/SplitTransactionUpdate.ts	`91.29% <100.00%> (+0.11%)`	⬆️
... and 535 files with indirect coverage changes

rlinoz · 2026-08-19T22:05:20Z

Please read our AI_ETIQUETTE, the whole conversation in this PR is really bad to follow.

With that said, if we can't selectors to onyx this makes this change probably not effective, no?

…ferred write

Abdukhamid000 · 2026-08-19T22:42:03Z

You're right. Whole-collection useOnyx re-subscribes the page, so that optimization was gone either way — I've dropped it. SplitExpensePage is now identical to main.

Selectors don't fit: allReportNameValuePairsList is also read per split transaction at SplitTransactionUpdate.ts:1375, keyed on IDs only known at save time.

This PR is now just the deferred write. Sorry for the noise above.

…2-defer-split-save # Conflicts: # tests/actions/IOUTest/SplitTest.ts

rlinoz · 2026-08-24T13:35:19Z

+    // API.write() applies optimisticData synchronously, so the destination screen re-renders from the
+    // transaction, report and report-action collections this write touches while the press is still
+    // trying to paint. Inside the split-expenses flow there is always a navigation to hide behind, so
+    // defer the write until that screen transition has finished. Outside it there is no transition to
+    // wait on, and a default barrier would stall the write for ~2s, so write immediately instead.


One last thing, can we simplify this comment please?

Done — two lines now, in 3f3b68d.

Claude-Session: https://claude.ai/code/session_01QTuQU9xaXExfVseQ36cgJp

rlinoz · 2026-08-24T15:07:05Z

@ikevin127 can you complete the checklist please?

mountiny · 2026-08-24T20:17:02Z

@JakubKorytko Can you please review this PR as well?

JakubKorytko · 2026-08-25T08:56:02Z

Yeah, I took a look earlier but will do a proper review today

JakubKorytko

some comments

JakubKorytko · 2026-08-25T10:38:52Z

+/**
+ * Re-exported from the real module so the mock matches its full surface. A suite that mocks this module and
+ * also feeds this constant into timer control (as `tests/unit/APIWriteWhenReadyTest.ts` does) would otherwise
+ * read `undefined` and fail somewhere that points nowhere near this file.
+ */


Suggested change

/**

* Re-exported from the real module so the mock matches its full surface. A suite that mocks this module and

* also feeds this constant into timer control (as `tests/unit/APIWriteWhenReadyTest.ts` does) would otherwise

* read `undefined` and fail somewhere that points nowhere near this file.

*/

seems kinda obvious as we do it for all mocks, a one short sentence would be enough or just remove

Cut to one sentence.

Claude-Session: https://claude.ai/code/session_01QTuQU9xaXExfVseQ36cgJp

JakubKorytko

a lot better now, one comment not super important though

JakubKorytko

won't harass you anymore, thanks for addressing the review

rlinoz · 2026-08-27T11:24:59Z

bump @ikevin127 on the checklist

ikevin127

Reviewer Checklist

Screenshots/Videos

Android: HybridApp

android.mp4

iOS: HybridApp

multi-ios.mov

iOS: mWeb Safari

Single	Multi
single-ios-mweb.mov	multi-ios-mweb.mov

Multi (reduced padding)
ios-mweb-padding-2.mov

MacOS: Chrome / Safari

Single	Multi
single.mov	multi.mov

Abdukhamid000 added 4 commits August 6, 2026 19:09

melvin-bot Bot assigned Abdukhamid000 Aug 6, 2026

Abdukhamid000 mentioned this pull request Aug 7, 2026

[$250] [INP] Improve SplitExpense-SaveButton interaction #97802

Open

Abdukhamid000 force-pushed the fix/97802-defer-split-save branch from af39069 to e997be4 Compare August 7, 2026 10:33

Abdukhamid000 removed their assignment Aug 7, 2026

chatgpt-codex-connector Bot reviewed Aug 10, 2026

View reviewed changes

Comment thread src/libs/actions/IOU/SplitTransactionUpdate.ts Outdated

Abdukhamid000 marked this pull request as ready for review August 11, 2026 07:47

Abdukhamid000 requested review from a team as code owners August 11, 2026 07:47

melvin-bot Bot requested review from a team, JmillsExpensify and ikevin127 and removed request for a team August 11, 2026 07:47

melvin-bot Bot requested review from rlinoz and removed request for a team August 11, 2026 07:47

melvin-bot Bot removed the request for review from a team August 11, 2026 07:47

chatgpt-codex-connector Bot reviewed Aug 11, 2026

View reviewed changes

Comment thread src/libs/actions/IOU/SplitTransactionUpdate.ts Outdated

JmillsExpensify reviewed Aug 11, 2026

View reviewed changes

rlinoz requested changes Aug 18, 2026

View reviewed changes

Address review: read split-flow Onyx data with useOnyx instead of Ony…

ad21c9d

…x.connect getters

Abdukhamid000 force-pushed the fix/97802-defer-split-save branch from 6209581 to ad21c9d Compare August 19, 2026 05:11

Drop the SplitExpensePage subscription change; keep this PR to the de…

337eef9

…ferred write

Merge branch 'main' of https://github.com/Expensify/App into fix/9780…

3bd0b0c

…2-defer-split-save # Conflicts: # tests/actions/IOUTest/SplitTest.ts

Abdukhamid000 requested a review from rlinoz August 19, 2026 22:49

rlinoz requested changes Aug 24, 2026

View reviewed changes

Simplify the deferred-write comment

3f3b68d

Claude-Session: https://claude.ai/code/session_01QTuQU9xaXExfVseQ36cgJp

Abdukhamid000 requested a review from rlinoz August 24, 2026 13:43

rlinoz previously approved these changes Aug 24, 2026

View reviewed changes

JakubKorytko reviewed Aug 25, 2026

View reviewed changes

Address review: trim mock comments, assert the immediate write

9b60ac6

Claude-Session: https://claude.ai/code/session_01QTuQU9xaXExfVseQ36cgJp

Abdukhamid000 dismissed rlinoz’s stale review via 9b60ac6 August 25, 2026 10:55

Remove tsbuildinfo files committed by mistake

1b919f4

Claude-Session: https://claude.ai/code/session_01QTuQU9xaXExfVseQ36cgJp

Abdukhamid000 requested a review from JakubKorytko August 25, 2026 12:49

JakubKorytko approved these changes Aug 26, 2026

View reviewed changes

Comment thread tests/actions/IOUTest/SplitTest.ts

Make the selfDM split tests exercise the branch the mock selects

a9c6f84

Abdukhamid000 requested a review from JakubKorytko August 27, 2026 03:56

JakubKorytko approved these changes Aug 27, 2026

View reviewed changes

ikevin127 approved these changes Aug 27, 2026

View reviewed changes

melvin-bot Bot requested a review from rlinoz August 27, 2026 18:35

		allReportNameValuePairsList: getAllReportNameValuePairs(),
		allSnapshots: getAllSnapshots(),

Uh oh!

Conversation

Abdukhamid000 commented Aug 6, 2026 • edited by JmillsExpensify Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

JakubKorytko commented Aug 7, 2026

Uh oh!

github-actions Bot commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Abdukhamid000 commented Aug 10, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Abdukhamid000 commented Aug 11, 2026

Uh oh!

Abdukhamid000 commented Aug 11, 2026

Uh oh!

melvin-bot Bot commented Aug 11, 2026

Uh oh!

melvin-bot Bot commented Aug 11, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

JmillsExpensify left a comment

Choose a reason for hiding this comment

Uh oh!

rlinoz left a comment

Choose a reason for hiding this comment

Uh oh!

rlinoz Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

rlinoz Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

Abdukhamid000 Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

ikevin127 commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Abdukhamid000 commented Aug 19, 2026

Uh oh!

codecov Bot commented Aug 19, 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!

rlinoz commented Aug 19, 2026

Uh oh!

Abdukhamid000 commented Aug 19, 2026

Uh oh!

rlinoz Aug 24, 2026

Choose a reason for hiding this comment

Uh oh!

Abdukhamid000 Aug 24, 2026

Choose a reason for hiding this comment

Uh oh!

rlinoz commented Aug 24, 2026

Uh oh!

mountiny commented Aug 24, 2026

Uh oh!

JakubKorytko commented Aug 25, 2026

Uh oh!

JakubKorytko left a comment

Choose a reason for hiding this comment

Uh oh!

Abdukhamid000 commented Aug 6, 2026 •

edited by JmillsExpensify

Loading

github-actions Bot commented Aug 7, 2026 •

edited

Loading

ikevin127 commented Aug 19, 2026 •

edited

Loading

codecov Bot commented Aug 19, 2026 •

edited by github-actions Bot

Loading