Repository navigation
[Due for payment 2026-10-16] [$175] Home - marked as paid system message thread opens when opened from Recently added #99611
Description
Activity
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/e6b5a427206b3605bf00a62154a6406d3ef035a6461f2fab7967020168bc91c8You have been assigned to this deploy blocker because you recently merged this PR: #98611
@JS00001 @ShridharGoel you have been assigned to this deploy blocker because you reviewed the offending PR: #98611
👋 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.
- Find someone who can quickly fix the issue.
- Fix the issue yourself.
@thelullabyy you have been assigned to this deploy blocker because you authored the offending PR: #98611
💬 A slack conversation has been started in #expensify-open-source
🔍 Investigation Summary
Classification: Frontend bug (fix required in
Expensify/App)
Causing PR: #93451 - "[Home Page] Add Recently added slot to Home" by @adamgrzybowski (Medium confidence for the origin PR / High confidence on the root-cause code)
Not the cause: #98611 - the auto-flagged PR (see below)
Related Issues: Feature origin #90366 (the header standardization tracked by #98611)Recommendation: ROLL FORWARD (targeted fix)
Reverting the auto-flagged PR #98611 will not fix this bug — it does not touch the code that chooses which report opens. The fix is a small, targeted change to how the tapped expense's IOU action is resolved in the Recently added slot, so we should roll forward rather than revert.
Assigned: (kept existing melvin auto-assignees) + added @adamgrzybowski (author), @ZhenjaHorbach and @grgia (approving reviewers) of the origin PR #93451, since the fix belongs in that feature code.
Labels: No change.DeployBlockerCashis correctly retained (Frontend bug, App deploy blocked). NoDeployBlocker(Web) label was present, so none removed.📋 Detailed Analysis
Why #98611 is NOT the cause
PR #98611 ("Standardize Expense Report and Expense header…") is the PR Melvin auto-assigned because its author merged it and its BrowserStack field literally links to it. Its only change to the Recently added flow is a signature update in
RecentlyAddedSection/index.tsx:- setActiveTransactionIDs(siblingTransactionIDs, siblingDescriptorsByTransactionID).then(() => { + setActiveTransactionIDs(siblingTransactionIDs, undefined, siblingDescriptorsByTransactionID).then(() => {This inserts an
undefinedfor the newsnapshotHashparameter ofsetActiveTransactionIDs. It affects only the idempotency/dedup of the carousel's sibling transaction-ID list — it does not change whichreportIDis navigated to for the tapped expense. The navigation target is computed bygetReportIDToOpenForExpense(...), which #98611 does not modify (its file list contains neitherTransactionThreadNavigationUtils.ts,ReportActionsUtils.ts, noruseRecentlyAddedData.ts).Root Cause
The Recently added slot picks the IOU action for each expense here:
src/pages/home/RecentlyAddedSection/useRecentlyAddedData.ts#L275reportAction: getIOUActionForTransactionID(snapshotReportActions, transaction.transactionID),
getIOUActionForTransactionIDreturns the first report action matching the transaction:
src/libs/ReportActionsUtils.ts#L2697-L2702function getIOUActionForTransactionID(reportActions: ReportAction[], transactionID: string): OnyxEntry<ReportAction> { return reportActions.find((reportAction) => { const IOUTransactionID = isMoneyRequestAction(reportAction) ? getOriginalMessage(reportAction)?.IOUTransactionID : undefined; return IOUTransactionID === transactionID; }); }
When you Pay someone in a 1:1 DM and Mark as paid, the transaction has two IOU actions that both satisfy
isMoneyRequestAction(typeIOU) and both carry the sameIOUTransactionID:- the original CREATE money-request action (its
childReportIDis the expense/transaction thread), and - the PAY action (the "marked as paid" system message — its
childReportIDis the pay message thread).
.find()returns whichever appears first in the snapshot's report-actions array; when that is the PAY action,expense.reportActionbecomes the pay action.Navigation then uses that action's
childReportIDdirectly:
src/libs/TransactionThreadNavigationUtils.ts#L59-L60if (expense.reportAction?.childReportID) { return expense.reportAction.childReportID; }
So the app navigates to the "marked as paid" message thread instead of the expense — exactly the reported symptom.
Verification
- Affected files:
useRecentlyAddedData.ts(chooses the wrong IOU action) andTransactionThreadNavigationUtils.ts(getReportIDToOpenForExpense, which trusts that action'schildReportID). - These files are part of the Home / Recently added feature (introduced by [Home Page] Add Recently added slot to Home #93451 and iterated on a feature branch), which is why the bug is "N/A in prod — new feature." They are NOT in Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611's changeset.
- Reproduces on staging only, consistent with the feature not yet being in production.
Suggested fix direction
Resolve the expense's IOU action to the money-request (create/track) action rather than any IOU action — e.g. filter out
pay-type IOU actions ingetIOUActionForTransactionIDfor this call site, or select the action whoseoriginalMessage.typeis a request/track type, sogetReportIDToOpenForExpenselands on the expense's transaction thread instead of the pay message thread.- the original CREATE money-request action (its
9 remaining items
PR in review
- changed the title
[-]Home - marked as paid system message thread opens when opened from Recently added[/-][+][$175] Home - marked as paid system message thread opens when opened from Recently added[/+]on Sep 28, 2026 Job added to Upwork: https://www.upwork.com/jobs/~022104571101072413518
- changed the title
[-][$175] Home - marked as paid system message thread opens when opened from Recently added[/-][+][Due for payment 2026-10-16] [$175] Home - marked as paid system message thread opens when opened from Recently added[/+]on Oct 9, 2026 The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.6-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-10-16. 🎊
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]
Metadata
Metadata
Type
Projects
- Status
If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.
Version Number: 9.4.62-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #98611
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests
Action Performed:
Expected Result:
Expense report will open.
Actual Result:
marked as paid system message thread opens when opened from Recently added.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7243703_1787781935372.3.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @ZhenjaHorbach