[$250] Unread chat prompting action after receipt already added

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @heyjennahay
Slack conversation (hyperlinked to channel name): #Quality

Action Performed:

1. Receive a chat prompt requesting a receipt for an Expensify Card expense
2. Add the receipt to the expense
3. Wait several hours (or revisit the inbox later)
4. Open New Expensify Inbox
5. Observe the unread chat prompting the same action
6. Refresh the page
7. Check the expense in Classic and confirm the receipt is already attached

Expected Result:

The chat should update and no longer show as unread.

Actual Result:

The chat remains unread
Refreshing the page does not update the state
Classic confirms the receipt is already attached

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

The screenshot and Onyx data in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @twilight2294

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029624146138391439
• Upwork Job ID: 2029624146138391439
• Last Price Increase: 2026-03-05
• Automatic offers:
• abzokhattab | Reviewer | 110742675
• twilight2294 | Contributor | 110742676

[melvin-bot]

Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user receives a chat prompt requesting a receipt for an Expensify Card expense and adds the receipt, the chat remains unread even though the receipt is confirmed attached (verified in Classic). Refreshing the page does not resolve the stale unread state.

What is the root cause of that problem?

The replaceReceipt function (src/libs/actions/IOU/index.ts:12217-12330) — which handles receipt attachment — only updates the transaction's receipt data. It does not interact with the chat/report state in any way:

• No report action is created to acknowledge the receipt attachment (contrast with detachReceipt at line 12093 which does create a MANAGER_DETACH_RECEIPT report action)
• lastReadTime is not updated on the report
• No actionable whisper resolution is triggered — if the prompt is an ACTIONABLE_TRACK_EXPENSE_WHISPER, its resolution field is only set when the user explicitly taps Submit/Categorize/Share/Nothing buttons (see PureReportActionItem.tsx:944-1010), not when a receipt is attached
• notifyNewAction is never called, so the chat state doesn't refresh

The report's "unread" status is determined by comparing lastReadTime < lastVisibleActionCreated (src/libs/ReportUtils.ts:8831-8837). Since the receipt-request prompt set lastVisibleActionCreated to its creation timestamp, and replaceReceipt never updates lastReadTime, the report stays permanently unread.

Additionally, MANAGER_ATTACH_RECEIPT exists in CONST/index.ts:1318 but is explicitly labeled as an OldDot Action — it is not created by the New Expensify client, creating an asymmetry where Classic updates the chat on receipt attachment but New Expensify does not.

What changes do you think we should make in order to solve the problem?

The fix should happen on two fronts depending on which type of prompt is shown:

1. If the prompt is an ACTIONABLE_TRACK_EXPENSE_WHISPER: When replaceReceipt successfully attaches a receipt, the system should check if the transaction has an associated unresolved ACTIONABLE_TRACK_EXPENSE_WHISPER and auto-resolve it. This would involve:

• In replaceReceipt (src/libs/actions/IOU/index.ts), after updating the transaction, look up the report actions for the transaction's report to find any unresolved ACTIONABLE_TRACK_EXPENSE_WHISPER referencing this transaction ID
• Call dismissTrackExpenseActionableWhisper to resolve it, AND include an update to lastVisibleActionCreated (which dismissTrackExpenseActionableWhisper currently omits — see src/libs/actions/Report/index.ts:5175-5222)

2. If the prompt is a server-generated message (Concierge/system): The backend should mark the receipt-request report action as resolved when the ReplaceReceipt API processes the receipt. Alternatively, replaceReceipt on the client side should update lastReadTime on the parent report as part of its optimistic data, so the chat is marked as read after the user attaches the receipt.

3. Fix dismissTrackExpenseActionableWhisper regardless: This function sets resolution on the whisper but does NOT recalculate lastVisibleActionCreated on the report. When the whisper becomes invisible (resolved whispers are filtered out at src/libs/ReportActionsUtils.ts:1174-1177), lastVisibleActionCreated still points to the now-invisible whisper's timestamp, which can cause stale unread state. The function should include an optimisticReportLastData call to recalculate lastVisibleActionCreated based on the next most recent visible action.

What alternative solutions did you explore? (Optional)

• Only updating lastReadTime: This would mask the symptom (unread indicator) but wouldn't actually resolve the underlying prompt/whisper. The user would still see the "add receipt" prompt when opening the chat, even though the receipt is already attached.
• Server-side only fix: Having the backend resolve the prompt when processing ReplaceReceipt would work but wouldn't handle the optimistic UI update — the user would still see the stale state until the server response arrives.

Detailed Investigation

Root Cause Analysis

Receipt attachment flow (replaceReceipt):

• src/libs/actions/IOU/index.ts:12217-12330 — Only updates transaction.receipt and recalculates violations (for paid group policies). No report action, no lastReadTime update, no notifyNewAction call.
• src/libs/API/parameters/ReplaceReceiptParams.ts — API params contain only transactionID, receipt, receiptState, isSameReceipt. No reportActionID or reportID.

ACTIONABLE_TRACK_EXPENSE_WHISPER lifecycle:

• Created at src/libs/actions/IOU/index.ts:4367-4370 when tracking expenses outside policy expense chats
• Built by buildOptimisticActionableTrackExpenseWhisper at src/libs/ReportUtils.ts:7420-7453
• Sets lastReadTime = lastVisibleActionCreated = whisper.created at src/libs/actions/IOU/index.ts:2745-2746
• Resolved whispers become invisible at src/libs/ReportActionsUtils.ts:1174-1177
• Resolution only through explicit button actions (Submit/Categorize/Share/Nothing) — NO auto-resolution on receipt attachment

Unread determination:

• isUnread at src/libs/ReportUtils.ts:8819-8838 — lastReadTime < lastVisibleActionCreated
• readNewestAction at src/libs/actions/Report/index.ts:2201 — only called when user views a report, not on receipt attachment

dismissTrackExpenseActionableWhisper gap:

• src/libs/actions/Report/index.ts:5175-5222 — Sets resolution on the whisper but does NOT update lastVisibleActionCreated on the report
• Compare with Submit/Categorize/Share which go through getDeleteTrackExpenseInformation (src/libs/actions/IOU/index.ts:3140, 3194) which DOES recalculate lastVisibleActionCreated

Evidence Chain

1. Server creates receipt-request prompt → lastVisibleActionCreated set to prompt's timestamp
2. User attaches receipt → replaceReceipt() updates transaction only
3. No chat state update → lastReadTime remains older than lastVisibleActionCreated
4. isUnread() returns true → Chat shows as unread in LHN
5. Refreshing reloads from server which also has stale state → Unread persists

Relevant Code

• src/libs/actions/IOU/index.ts:12217-12330 — replaceReceipt function (missing chat state update)
• src/libs/actions/IOU/index.ts:12093-12215 — detachReceipt function (comparison — DOES create report action)
• src/libs/actions/Report/index.ts:5175-5222 — dismissTrackExpenseActionableWhisper (missing lastVisibleActionCreated update)
• src/libs/ReportUtils.ts:8819-8838 — isUnread function
• src/libs/ReportActionsUtils.ts:1174-1177 — Resolved whisper invisibility
• src/CONST/index.ts:1318 — MANAGER_ATTACH_RECEIPT labeled as OldDot Action

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abzokhattab (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022029624146138391439

[twilight2294]

🚨 Edited by proposal-police: This proposal was edited at 2026-03-05 19:39:15 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user receives a chat prompt requesting a receipt for an Expensify Card expense and attaches the receipt, the chat remains permanently marked as unread. Refreshing the page does not resolve the stale unread state.

What is the root cause of that problem?

The replaceReceipt() function in IOU only updates the transaction's receipt data in its optimistic updates. It does not update lastReadTime on either the transaction thread report or its parent IOU report. When the API processes ReplaceReceipt, it generates a MODIFIEDEXPENSE report action on the transaction thread. This action updates lastVisibleActionCreated via the server response, but since lastReadTime was never advanced, the report becomes permanently unread.

The isUnread() check in ReportUtils returns true whenever lastReadTime < lastVisibleActionCreated. Since replaceReceipt() never touches lastReadTime, and the server-side response bumps lastVisibleActionCreated via the new report action, this condition is permanently satisfied.

This is proven by contrast with getUpdateMoneyRequestParams() in IOU, which handles other transaction mutations (amount, merchant, date, etc.). That function creates an optimistic MODIFIEDEXPENSE report action and updates lastReadTime on both the transaction thread and the parent IOU report (lines 4625–4631 and 4726–4734). The replaceReceipt() function does neither.

Additionally, getReportLastVisibleActionCreated() in IOU takes the max of the parent report's and the one-transaction-thread's lastVisibleActionCreated. So the stale unread state propagates from the transaction thread up to the parent IOU report visible in the LHN.

What changes do you think we should make in order to solve the problem?

In replaceReceipt() in IOU, we should add optimistic data to update lastReadTime on both the transaction thread report and, for one-transaction-thread cases, the parent IOU report — mirroring the pattern used by getUpdateMoneyRequestParams().

Specifically, after the existing optimistic transaction update, add:

// Update lastReadTime on the transaction thread so the report isn't marked unread
// when the server creates a MODIFIEDEXPENSE action for the receipt change
const now = DateUtils.getDBTime();

optimisticData.push({
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.REPORT}${transactionThreadReportID}`,
    value: {
        lastReadTime: now,
    },
});

// For one-transaction threads, also update the parent IOU report
const transactionThreadReport = ReportConnection.getAllReports()?.[`${ONYXKEYS.COLLECTION.REPORT}${transactionThreadReportID}`];
const iouReport = transactionThreadReport?.parentReportID
    ? ReportConnection.getAllReports()?.[`${ONYXKEYS.COLLECTION.REPORT}${transactionThreadReport.parentReportID}`]
    : undefined;

if (isOneTransactionThread(transactionThreadReport ?? undefined, iouReport ?? undefined, undefined)) {
    optimisticData.push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.REPORT}${iouReport?.reportID}`,
        value: {
            lastReadTime: now,
        },
    });
}

This ensures that when the server response arrives with the new MODIFIEDEXPENSE action (updating lastVisibleActionCreated), the lastReadTime is already at or ahead of that timestamp, so isUnread() returns false.

What alternative solutions did you explore? (Optional)

The existing MelvinBot proposal suggests auto-resolving ACTIONABLE_TRACK_EXPENSE_WHISPER and fixing dismissTrackExpenseActionableWhisper. However, the issue is specifically about Expensify Card expenses where the prompt comes from a server-generated receipt request — not from the track expense whisper flow. The core problem is simpler: replaceReceipt() is missing the lastReadTime update that every other transaction mutation includes. My solution is more targeted — a single optimistic data addition in replaceReceipt() following the exact pattern already established by getUpdateMoneyRequestParams() — rather than touching multiple functions across the whisper resolution system.

[abzokhattab]

reviewing today