[Due for payment 2026-03-30] Expensify card - System message doesn't appear when there is a pending submit expense

[jponikarchuk]

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: v9.3.40-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176890/test-cases/41237378
Email or phone of affected tester (no customers): applausetester+ag180326d@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.3
App Component: Chat Report View

Action Performed:

Preconditions:
Use a new Expensifail account.
Have a workspace with Expensify cards enabled.
Have a draft expense report in the Expensify cards workspace.

1. Open the Expensify app
2. Issue an Expensify virtual card to yourself
3. Go to workspace chat

Expected Result:

There's a system message indicating that the Expensify card was assigned to you.

Actual Result:

The system message doesn't appear when there is a draft expense report.
After deleting the expense report, the message appears.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @hoangzinh

[melvin-bot]

Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 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:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85192 - "feat: deep link to report preview or message that caused GBR/RBR" by @aimane-chnaif (High confidence)
Related Issues: None

Recommendation: REVERT

The PR #85192 introduces logic that filters report actions for display in the workspace chat based on specific criteria (Pay, Approve, Submit actions). However, CARD_ISSUED system messages are not being properly considered in this new filtering logic, causing them to not appear when draft expense reports exist.

Labels: Keeping DeployBlockerCash (App deploy is blocked), as this is a frontend bug requiring changes to the App repository.

Detailed Analysis

Evidence

• The bug is reproducible only on staging (v9.3.40-0), not production
• PR feat: deep link to report preview or message that caused GBR/RBR #85192 was merged on March 18, 2026, and is included in the current staging deploy
• The PR modifies how report actions are displayed in the LHN (Left Hand Navigation) by introducing deep linking to GBR/RBR (Green/Red Badge Reports)
• The changes affect reportAttributes.ts, ReportUtils.ts, SidebarUtils.ts, and the core display logic for action badges

Verification

Files affected by the bug:

• /home/runner/_work/App/App/src/libs/ReportUtils.ts (line 4346: getIOUReportActionWithBadge function)
• /home/runner/_work/App/App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts (reportAttributes configuration)
• /home/runner/_work/App/App/src/libs/actions/IOU/index.ts (line 9809: getIOUReportActionWithBadge function)

The PR modifies how system messages are filtered and displayed:

1. The getIOUReportActionWithBadge function only looks for REPORT_PREVIEW actions (expense report summaries)
2. CARD_ISSUED actions are a different action type (CONST.REPORT.ACTIONS.TYPE.CARD_ISSUED)
3. When a draft expense report exists, the new filtering logic focuses on expense-related actions and inadvertently filters out card issuance messages

Root Cause

PR #85192 introduced getReasonAndReportActionThatRequiresAttention changes that prioritize expense report actions (REPORT_PREVIEW) over other system messages. The getIOUReportActionWithBadge function specifically filters for actions where the user can pay, approve, or submit, which excludes CARD_ISSUED actions. When a draft expense report is present, the system focuses on these expense actions and the CARD_ISSUED message does not appear in the workspace chat.

The issue disappears after deleting the draft expense report because the filtering logic no longer has expense reports to prioritize, allowing the CARD_ISSUED system message to be displayed normally.

[MelvinBot]

Proposal

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

When a workspace has an Expensify card assigned and a pending/draft expense report exists, the CARD_ASSIGNED system message doesn't appear in the workspace chat. After deleting the expense report, the message appears. This is reproducible on staging but not on production, indicating a regression.

What is the root cause of that problem?

PR #85192 (merged March 18) introduced a new feature that deep-links to specific report actions when clicking a chat in the LHN sidebar. This feature is gated to staging only via an isProduction check:

src/pages/inbox/sidebar/SidebarLinks.tsx:76:

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(option.reportID, isProduction ? undefined : option.actionTargetReportActionID));

When a draft expense report exists, the system computes an actionTargetReportActionID pointing to the REPORT_PREVIEW action (the one with the Submit badge). This flows through:

1. reportAttributes.ts:246 — derives actionTargetReportActionID from the GBR/RBR target
2. OptionRowLHNData → SidebarLinks → navigation route params
3. usePaginatedReportActions.ts:48 — uses the reportActionID from route as the pagination anchor

The critical issue is in PaginationUtils.ts:225-228:

// If we are linked to an action in a gap return it by itself
if (!linkedPage && resourceItem) {
    return {data: [resourceItem.item], hasNextPage: false, hasPreviousPage: false, resourceItem};
}

The REPORT_PREVIEW action for a draft expense was created optimistically (by the IOU action, not via OpenReport), so it's not in any server-fetched page. When the user clicks the workspace chat in the LHN:

• Navigation deep-links to the REPORT_PREVIEW action ID (staging only)
• getContinuousChain finds this action in a "pagination gap" (exists in Onyx but not in any page)
• It returns only that single REPORT_PREVIEW action, hiding all other actions including CARD_ASSIGNED

When the expense report is deleted, actionTargetReportActionID is no longer set → navigation proceeds without a deep-link → getContinuousChain returns the first page with all actions → CARD_ASSIGNED becomes visible again.

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

Fix getContinuousChain in src/libs/PaginationUtils.ts at lines 225-228. When the linked action is in a pagination gap and loaded pages already exist, fall back to the first page instead of returning the linked action in isolation. The resourceItem can still be returned so the UI can scroll to the target action.

This way, when the LHN deep-links to a REPORT_PREVIEW that was optimistically created (and therefore not in any page), the user still sees the full chat content rather than just that one action.

What alternative solutions did you explore? (Optional)

1. Fix at the navigation level (SidebarLinks.tsx): Only pass actionTargetReportActionID when the action is confirmed to be in a loaded page. Rejected because SidebarLinks doesn't have access to pagination data.
2. Fix in reportAttributes.ts: Don't set actionTargetReportActionID for optimistic/pending actions. This is more targeted but would miss the general case where any deep-linked action could be in a gap.
3. Fix in usePaginatedReportActions.ts: Detect when the chain has only one item in a gap and fall back. This is equivalent to the recommended fix but at the wrong abstraction layer.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.