[$250] Card Assignment System Message Not Triggered When Draft Expense Exists in Report

[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: @aimane-chnaif
Slack conversation (hyperlinked to channel name): #Convert

Action Performed:

Precondition: Have a new workspace with Expensify cards feature enabled.

1. Go to workspace chat
2. Create a draft expense
3. Long press on the report preview and copy link
4. Paste link somewhere (i.e. in self DM)
5. Issue an Expensify virtual card to yourself
6. Go to the chat where link is pasted (i.e. self DM)
7. Tap the link

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:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

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

bug.mov

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039689059420833339
• Upwork Job ID: 2039689059420833339
• Last Price Increase: 2026-04-23

[samranahm]

Proposal

What is the root cause of that problem?

The card assignment system message is added to the workspace policy expense chat by first finding that chat with getPolicyExpenseChat(...).

That lookup currently searches only the main REPORT collection. When a draft expense exists, the policy expense chat can exist only in REPORT_DRAFT at that moment. In this state, getPolicyExpenseChat(...) returns undefined, so the optimistic CARD_ASSIGNED action is merged into an invalid report-actions key instead of the real policy expense chat.

Result: the assignment succeeds, but the system message is not visible until the draft is removed and a non-draft policy expense chat is available.

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

We should update getPolicyExpenseChat(...) to:

1. Keep existing behavior first: search the main REPORT collection.
2. If not found (and default report source is used), fall back to searching REPORT_DRAFT.

This ensures card-assignment optimistic/system actions always target a valid policy expense chat report ID, even when that chat exists only as a draft.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[aimane-chnaif]

The root cause is same as #85744

[MelvinBot]

Proposal

What is the root cause of that problem?

The card system message (e.g. CARD_ISSUED_VIRTUAL) is created entirely server-side and delivered to the client via Pusher/Onyx updates. When the message arrives, it is merged into REPORT_ACTIONS for the workspace chat. However, it bypasses the Pagination middleware (App/src/libs/Middleware/Pagination.ts), meaning REPORT_ACTIONS_PAGES is NOT updated to include this new action.

Meanwhile, when the draft expense exists (submitted but not yet approved), the expense submission's API response (requestMoney) does go through the Pagination middleware, which sets REPORT_ACTIONS_PAGES for the workspace chat. If the card system message arrives after this pagination state is established, it exists in REPORT_ACTIONS in Onyx but may fall outside the page boundaries tracked by REPORT_ACTIONS_PAGES.

The rendering pipeline in ReportActionsView uses usePaginatedReportActions which relies on getContinuousChunk from PaginationUtils to determine which actions to display. If the new card action's position isn't covered by the current page boundaries, it won't be included in the rendered list — even though it's in Onyx.

When the draft expense is deleted, the user navigates back to the workspace chat, which triggers ReportFetchHandler to call openReport(). This API call goes through the Pagination middleware and properly refreshes REPORT_ACTIONS_PAGES, now including the card system message. This is why the message appears after deletion.

A contributing factor: the optimistic CARD_ASSIGNED action (for company card assignment via CompanyCards.ts:421) is built with empty message[0].html: '' (ReportUtils.ts:8378), which causes isDeletedAction() (ReportActionsUtils.ts:219) to return true. While pendingAction is set, the action is still visible (line 1235), but once cleared, it could become invisible if the server also returns empty html (since the display text is generated client-side via getCardIssuedMessage()).

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

Two fixes should be applied:

1. Exempt card system messages from isDeletedAction: In App/src/libs/ReportActionsUtils.ts, add an early return in isDeletedAction() for card-related action types (similar to how HOLD/UNHOLD and REIMBURSEMENT_DIRECTOR_INFORMATION_REQUIRED are exempted). Card actions like CARD_ASSIGNED, CARD_ISSUED_VIRTUAL, CARD_ISSUED, CARD_MISSING_ADDRESS, CARD_REPLACED_VIRTUAL, and CARD_REPLACED have empty html by design since their display text is generated client-side by getCardIssuedMessage(). They should never be treated as deleted:

   if (isCardIssuedAction(reportAction)) {
       return false;
   }
   

2. Ensure Pusher-delivered actions update pagination state: When new report actions arrive via Pusher (in App/src/libs/actions/User.ts), ensure that REPORT_ACTIONS_PAGES is updated to include the new action IDs, particularly when the action is newer than any existing page boundary. This prevents the pagination gap that hides newly arrived server-side actions.

What alternative solutions did you explore? (Optional)

• Populate html in the optimistic action: Instead of building the optimistic CARD_ASSIGNED action with empty html, we could pre-populate it with the translated message from getCardIssuedMessage(). This would fix the isDeletedAction false positive but wouldn't address the pagination gap issue for server-only actions like CARD_ISSUED_VIRTUAL.
• Force re-fetch on navigation: Adding an openReport() call when navigating to a workspace chat via deep link would ensure fresh data, but this is a workaround rather than a fix and adds unnecessary network requests.

---

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

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[trasnake87]

Proposal

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

When a user navigates to a workspace chat via a deep link (e.g., tapping a copied report preview link) after a card assignment system message was delivered in real-time, the system message is not displayed if a draft expense exists in the report. The message only appears after the draft is deleted and the report is re-fetched.

What is the root cause of that problem?

When navigating via deep link, openReport is called with reportActionID as the pagination cursor (https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1629). The server returns a page of actions centered around that cursor. Since the card system message is newer than the linked action, the server sets hasNewerActions=true, and the returned page does NOT get PAGINATION_START_ID (https://github.com/Expensify/App/blob/main/src/libs/Middleware/Pagination.ts#L113-L116). The card action was already delivered via Pusher into REPORT_ACTIONS in Onyx, but Pusher updates never touch REPORT_ACTIONS_PAGES. In usePaginatedReportActions, getContinuousChain (https://github.com/Expensify/App/blob/main/src/hooks/usePaginatedReportActions.ts#L75) only returns the page containing the linked action, excluding the newer card action even though it exists in Onyx. Without the draft expense, openReport is called without a cursor, so the page gets PAGINATION_START_ID which dynamically extends to index 0, including any Pusher-delivered actions.

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

We should fix usePaginatedReportActions (https://github.com/Expensify/App/blob/main/src/hooks/usePaginatedReportActions.ts#L70-L76) to include real-time actions that are already in Onyx but fall outside the current page boundaries. After getContinuousChain returns the paginated result, if hasPreviousPage is true (newer actions exist), we prepend any actions from sortedAllReportActions that are newer than the first paginated action:

const {
    data: reportActions,
    hasNextPage,
    hasPreviousPage,
    resourceItem,
} = useMemo(() => {
    if (!sortedAllReportActions?.length) {
        return {data: [], hasNextPage: false, hasPreviousPage: false};
    }

    const result = PaginationUtils.getContinuousChain(sortedAllReportActions, reportActionPages ?? [], (reportAction) => reportAction.reportActionID, id);

    // Include real-time actions (e.g. Pusher-delivered) that are newer than the
    // current page but already in Onyx. Without this, system messages like card
    // assignments won't appear when navigating via deep link with a cursor.
    if (result.hasPreviousPage && result.data.length > 0) {
        const newestPagedID = result.data[0]?.reportActionID;
        const idx = sortedAllReportActions.findIndex((a) => a.reportActionID === newestPagedID);
        if (idx > 0) {
            return {...result, data: [...sortedAllReportActions.slice(0, idx), ...result.data], hasPreviousPage: false};
        }
    }

    return result;
}, [id, reportActionPages, sortedAllReportActions]);

This ensures that when the paginated view is missing newer actions that were delivered in real-time, they are included at the consumer level without modifying the pagination data layer. The fix is safe because these actions are already validated and present in Onyx — we are simply bridging the gap between the real-time data store and the pagination boundary.