[$250] Report - “marked as paid, saying [comment]" not display in ND after admin paid expense in OD

[applause-bot]

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.82-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-33365/folder/13176703/41236815/1439060672
Email or phone of affected tester (no customers): lekima20+625205@gmail.com (employee), lekima20+625005@gmail.com (admin)
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

Precondition: Admin create a workspace setting Submissions manually, enable Approvals and Payments. Invite an employee to workspace chat

1. Open https://staging.new.expensify.com
2. Employee navigate to OD create a report with expense
3. Employee submit the report
4. Employee navigate to ND open the submitted report at step 3
5. Employee add a comment
6. Admin navigate to OD open the employee submitted report at step 3
7. Admin click Approve and select Final approve
8. Admin click on dropdown reimburse and select "I'll do it manually - just mark it as reimbursed"
9. Admin add a comment and click on Mark as Reimbursed
10. Employee in ND refresh page and open this paid report

Expected Result:

Verify a system message on the expense report from the payer that reads: “marked as paid, saying [comment]”

Actual Result:

Employee only see the Approved message

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7163143_1779767045966.Recording__2156.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7163143

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059181338805929902
• Upwork Job ID: 2059181338805929902
• Last Price Increase: 2026-05-26

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/68c9403b896ae2e0f2e042c4de3402d51b90b98c9b9579c9f601b969595179d8

[MelvinBot]

Proposal

What is the root cause of that problem?

The New Dot frontend correctly supports displaying the MARKEDREIMBURSED report action created when an admin marks a report as manually reimbursed in Old Dot. The visibility filter at ReportActionsUtils.ts:1261-1265 only hides these actions when originalMessage.isNewDot === true or reportAction.shouldShow === false — neither should apply to OldDot-originated actions.

The rendering path is also correct: SimpleMessageContent.tsx:52-53 renders MARKEDREIMBURSED via getMarkedReimbursedMessage(), which produces the expected "marked as paid, saying [comment]" string using the iou.paidElsewhere translation.

Since the entire frontend pipeline is correct, the root cause is on the backend side — either the MARKEDREIMBURSED report action is not being created/pushed to New Dot clients when the admin marks as reimbursed in Old Dot, or the backend is setting shouldShow: false on the action (which would cause the frontend filter to hide it).

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

This appears to be a backend/internal issue. A separate internal investigation is needed to determine:

1. Whether the MARKEDREIMBURSED action is being created when an admin marks a report as manually reimbursed in Old Dot
2. Whether it's included in the OpenReport API response and/or pushed via Pusher to the employee's New Dot client
3. Whether the action's shouldShow field is being set to false by the backend

The fix will be on the backend to ensure the MARKEDREIMBURSED action is properly created (with shouldShow not set to false and isNewDot not set to true) and delivered to New Dot clients.

Investigation details

Frontend code trace (all correct):

1. Action type defined at CONST/index.ts:1521 — MARKED_REIMBURSED: 'MARKEDREIMBURSED' (labeled as OldDot Action)
2. Visibility filter at ReportActionsUtils.ts:1260-1266 — hides MARKEDREIMBURSED only when isNewDot === true OR shouldShow === false
3. Rendering at SimpleMessageContent.tsx:52-53 — dispatches to getMarkedReimbursedMessage()
4. Message formatting at ReportActionsUtils.ts:461-463 — extracts comment from originalMessage.message
5. Translation at en.ts:1431 — produces "marked as paid, saying \"[comment]\""

Key distinction: NewDot uses IOU PAY actions with paymentType: ELSEWHERE for its own "mark as paid" flow (PayMoneyRequest.ts:827-835). OldDot uses the MARKEDREIMBURSED action type instead. Both paths are supported in the frontend.

Possibly related: #89131 ("Marked as paid message is shown twice") — may share underlying backend logic for creating/delivering MARKEDREIMBURSED actions.

---

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.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The MARKED_REIMBURSED report action created by OldDot when an admin marks a report paid is delivered to NewDot via Pusher, but NewDot doesn't have a dedicated rendering path that surfaces the admin's comment. The action makes it past visibility filtering:

https://github.com/Expensify/App/blob/main/src/libs/ReportActionsUtils.ts#L1274-L1280

// Hide REIMBURSED and MARKED_REIMBURSED actions created from NewDot since an IOU PAY action is displayed instead
if (isActionOfType(reportAction, CONST.REPORT.ACTIONS.TYPE.REIMBURSED) || isActionOfType(reportAction, CONST.REPORT.ACTIONS.TYPE.MARKED_REIMBURSED)) {
    const originalMessage = getOriginalMessage(reportAction);
    if (originalMessage?.isNewDot) {
        return false;
    }
}

For an OldDot-originated MARKED_REIMBURSED, originalMessage.isNewDot is false, so the action is included in the visible list. But there's no specific rendering branch for it — no case CONST.REPORT.ACTIONS.TYPE.MARKED_REIMBURSED exists in ReportActionItem or in any sibling renderer. The action falls through to the generic getReportActionText fallback, which reads reportAction.message[0].text.

OldDot delivers this action with the comment embedded in originalMessage.reason (or similar field), not in message[0].text — so the generic fallback finds nothing displayable and the action renders as empty. The repro confirms: after step 9, the employee sees the "Approved" message but not the "marked as paid, saying [comment]" line, because the MARKED_REIMBURSED action lands in REPORT_ACTIONS but has no rendering pipeline to surface the comment.

In contrast, the IOU.PAY action that NewDot uses internally has its own rendering with the comment correctly surfaced (which is why the same "marked as paid, saying X" works when both sides are NewDot).

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

Add a rendering branch for OldDot-originated MARKED_REIMBURSED actions that produces the same "marked as paid, saying [comment]" string the IOU.PAY action produces. The simplest place is in the message-derivation utility that already handles other action types:

1. Build the translation-key plumbing. In src/libs/ReportActionsUtils.ts, add a helper that produces the message text from a MARKED_REIMBURSED action's originalMessage:

function getMarkedReimbursedMessage(action: ReportAction, translate: LocalizedTranslate): string {
    const originalMessage = getOriginalMessage(action as ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.MARKED_REIMBURSED>);
    const reason = originalMessage?.reason ?? originalMessage?.markedAsReimbursedReason ?? '';
    if (reason) {
        return translate('iou.markedAsPaidWithComment', {comment: reason});
    }
    return translate('iou.markedAsPaid');
}

The exact field name (reason vs. markedAsReimbursedReason vs. another) is what OldDot emits in originalMessage; both should be checked since the OldDot payload shape can vary by version.

2. Wire the helper into the action renderer. Where ReportActionItem resolves the message text for each action type, add a branch:

+ } else if (action.actionName === CONST.REPORT.ACTIONS.TYPE.MARKED_REIMBURSED) {
+     messageText = getMarkedReimbursedMessage(action, translate);
+     return <RenderReportActionItemMessage message={messageText} ... />;
+ } else if (...

Or, if the generic pipeline is the right place, replace the generic getReportActionText fallback for MARKED_REIMBURSED with the helper above so any caller that derives the text via getReportActionText also produces the comment-bearing string.

3. Add the translation keys in every locale:

iou: {
    ...
    markedAsPaid: 'marked the report as paid',
    markedAsPaidWithComment: ({comment}: {comment: string}) => `marked the report as paid, saying "${comment}"`,
}

After this, an OldDot MARKED_REIMBURSED action delivered to NewDot:

• Still passes the visibility check (isNewDot === false, so it's not hidden).
• Now renders the "marked as paid, saying [comment]" line using the comment field OldDot included in originalMessage.

What alternative solutions did you explore?

N/A

[melvin-bot]

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

[aswin-s]

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

When an admin marks an expense report as reimbursed manually from OldDot (with a comment), the employee viewing the report in NewDot never sees the expected system message "marked as paid, saying [comment]" — only the earlier "Approved" message is shown. The marked-as-paid system message should be visible in NewDot for reimbursements that originate in OldDot.

What is the root cause of that problem?

In src/libs/ReportActionsUtils.ts (shouldReportActionBeVisible, lines 1260-1266), the MARKED_REIMBURSED action is hidden when originalMessage?.isNewDot || reportAction.shouldShow === false. The || reportAction.shouldShow === false clause was added by commit bd7e106a ("fix marked as paid message is shown twice on receipt expense", 2026-05-05). The original isNewDot guard intentionally hides the action only when an IOU PAY action is displayed instead. But shouldShow is a generic backend-set flag on ReportAction (src/types/onyx/ReportAction.ts:176), and for an OldDot-originated MARKED_REIMBURSED action there is no replacement IOU PAY action — so this clause hides the only payment message, leaving the employee with just the Approved message.

The key distinction: NewDot-originated MARKED_REIMBURSED actions have originalMessage.isNewDot === true, while OldDot-originated ones have isNewDot absent (undefined). The bd7e106a fix applied shouldShow === false suppression to all MARKED_REIMBURSED actions regardless of origin, but it should only apply when the action is NewDot-originated (i.e. when a duplicate IOU PAY action exists to replace it).

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

1. src/libs/ReportActionsUtils.ts lines 1260-1266: scope the shouldShow === false suppression so it only fires when the action is NewDot-originated. The fix is to require isNewDot === true before allowing shouldShow to suppress the action:

// Before (bd7e106a):
if (originalMessage?.isNewDot || reportAction.shouldShow === false) {
    return false;
}

// After:
if (originalMessage?.isNewDot) {
    return false;
}
if (originalMessage?.isNewDot === true && reportAction.shouldShow === false) {
    return false;
}

More concisely, collapse into a single condition:

if (originalMessage?.isNewDot === true) {
    return false;
}

This ensures OldDot-originated actions (where isNewDot is undefined) are never suppressed by the shouldShow path, while NewDot-originated duplicates (where isNewDot === true) remain hidden as intended by bd7e106a.

2. Confirm the original "shown twice on receipt expense" scenario (the case bd7e106a fixed) still de-duplicates after the change — those duplicate actions are NewDot-originated (isNewDot === true) and remain covered by the updated condition.

3. Add/extend a test in tests/ui/PureReportActionItemTest.tsx (which already asserts getByText(/marked as paid/i)) to cover an OldDot-originated MARKED_REIMBURSED action with shouldShow === false and isNewDot absent, asserting the message stays visible with its comment.

What alternative solutions did you explore? (Optional)

Revert bd7e106a entirely, but that would reintroduce the duplicate "marked as paid" message on receipt expenses; scoping the condition to isNewDot === true preserves both fixes.

[melvin-bot]

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

[lxyct825-ops]

Proposal

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

Report - “marked as paid, saying [comment]" not display in ND after admin paid expense in OD

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.