You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expense-Unable to switch off "reimbursable" toggle when creating expense #105205
Version Number: v9.5.24-2 Reproducible in staging?: Yes Reproducible in production?: No If this was caught during regression testing, add the test name, ID and link from BrowserStack:#103211 Email or phone of affected tester (no customers):[email protected] Issue reported by: Applause Internal Team Bug source: Exploratory - Significant User Experience Deterioration Device used: Desktop / Windows 11 App Component: Chat Report View
Action Performed:
Open the Expensify Web App and log in
Create a workspace
Click on the "+" button and click on "Create expense"
Switch to manual and scroll down
Try to switch off the "reimbursable" toggle
Expected Result:
The user should be able to switch off the reimbursable toggle when creating an expense.
Actual Result:
The user cannot switch off the reimbursable toggle when creating an expense.
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
Identify the pull request that introduced this issue and revert it.
Root cause: The PR replaced a useMemo keyed only on transactions.length with a plain transactions.map(...) in IOURequestStepConfirmation/index.tsx:175. Now every draft edit creates a new transactionIDs array. That re-runs the effects in ExpenseDefaultsSetter.tsx:26-43, which reset reimbursable and billable to the policy defaults. Turning Reimbursable off writes false, then the effect immediately writes true back.
Recommendation: roll forward with a small fix. Reverting a 932-file PR in a cherry-pick will likely conflict. Keep revert as the fallback.
Make transactionIDs change only when the set of IDs changes:
// Key on the IDs alone so editing a draft's details doesn't re-run the defaults setters and overwrite what the user picked.consttransactionIDsKey=transactions.map((item)=>item.transactionID).join(',');consttransactionIDs=transactionIDsKey ? transactionIDsKey.split(',') : [];
Retest after the fix:
Billable toggle (same bug).
Editing merchant, amount, or description no longer resets reimbursable or billable.
The removed code was intentional. Its comment read: "Depend on transactions.length to avoid updating transactionIDs when only the transaction details change", followed by an eslint-disable for react-hooks/exhaustive-deps. React Compiler memoizes on the whole transactions array, so that narrowing was lost.
transactions comes from the full draft objects, so any field change produces a new array.
Code review rule suggestion (for human review): Add a rule to app-coding-standards that flags removing a useMemo/useCallback whose deps were deliberately narrowed (preceded by eslint-disable-next-line react-hooks/exhaustive-deps, or deps like x.length). Ask the author to keep the narrowed identity with a primitive key instead, such as a joined ID string. #104522 makes manual memoization a lint error, so more of these removals are likely.
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.24-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]
Activity
applause-bot commentedon Oct 27, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/570bead1c4af3ae35a079f7bdbbb18a602caa45a2cfae61d34bbac8566962d90
melvin-bot commentedon Oct 27, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #103211
melvin-bot commentedon Oct 27, 2026
@Beamanator you have been assigned to this deploy blocker because you reviewed the offending PR: #103211
melvin-bot commentedon Oct 27, 2026
@c3024 you have been assigned to this deploy blocker because you authored the offending PR: #103211
melvin-bot commentedon Oct 27, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Oct 27, 2026
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
MelvinBot commentedon Oct 27, 2026
Deploy Blocker Investigation
Causing PR: [No QA] Disallow manual memoization in compiled React code (
Expensify/App#104522), not the auto-assigned [CP Staging] Revert "Add Vendor filter to expense Search". High confidence.Root cause: The PR replaced a
useMemokeyed only ontransactions.lengthwith a plaintransactions.map(...)in IOURequestStepConfirmation/index.tsx:175. Now every draft edit creates a newtransactionIDsarray. That re-runs the effects in ExpenseDefaultsSetter.tsx:26-43, which reset reimbursable and billable to the policy defaults. Turning Reimbursable off writesfalse, then the effect immediately writestrueback.Recommendation: roll forward with a small fix. Reverting a 932-file PR in a cherry-pick will likely conflict. Keep revert as the fallback.
Make
transactionIDschange only when the set of IDs changes:Retest after the fix:
transactionIDs).Assignees:
roryabraham(author) andchrispader/mountiny(approvers) own this.c3024andBeamanatorwere auto-assigned in error and can be unassigned.Investigation details
5cb8254). It's in v9.5.24-2 on staging but not production, which matches the repro.eslint-disableforreact-hooks/exhaustive-deps. React Compiler memoizes on the wholetransactionsarray, so that narrowing was lost.transactionscomes from the full draft objects, so any field change produces a new array.Code review rule suggestion (for human review): Add a rule to
app-coding-standardsthat flags removing auseMemo/useCallbackwhose deps were deliberately narrowed (preceded byeslint-disable-next-line react-hooks/exhaustive-deps, or deps likex.length). Ask the author to keep the narrowed identity with a primitive key instead, such as a joined ID string. #104522 makes manual memoization a lint error, so more of these removals are likely.view run
test: cover expense toggle choices surviving edits
fix: preserve expense choices across draft edits
m-natarajan commentedon Oct 28, 2026
This issue is not repro on windows10/chrome and iphone 11/26.2 (Pending validation in Android) build 9.5.24-5
ScreenRecording_10-28-2026.17-13-15_1.MP4
Recording.1936.mp4
melvin-bot commentedon Oct 29, 2026
@roryabraham @c3024
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.24-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]