Report log shows incomplete history

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

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: @greg-schroeder
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open report in New Expensify
2. View the report's audit log / history in the UI
3. Download the report as a PDF
4. Compare the audit log entries shown in the UI against those in the PDF

Expected Result:

Every audit log action present in the exported PDF should also be visible in the New Expensify report history UI; the UI and PDF should be consistent

Actual Result:

Many audit log actions that appear in the exported PDF are not shown in the Expensify UI

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

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082481508844422360
• Upwork Job ID: 2082481508844422360
• Last Price Increase: 2026-07-29

[MelvinBot]

Issue Analysis

Root Cause: The NewDot report history is filtered entirely client-side by shouldReportActionBeVisible in src/libs/ReportActionsUtils.ts. The report actions themselves are delivered to the client and stored in Onyx — nothing is withheld by the backend — but this function drops many of them at render time. The exported PDF is generated by the backend (OldDot) from the full, unfiltered history, so it will always contain more entries than the UI. The UI/PDF divergence is therefore expected behavior for several categories, and a partly-fixable gap for two others.

Two categories are the actionable cause of "audit entries in the PDF but not in the UI":

1. Deprecated OldDot action types — the deprecatedOldDotReportActions blocklist explicitly hides DELETED_ACCOUNT, REIMBURSEMENT_REQUESTED, REIMBURSEMENT_SETUP_REQUESTED, and DONATION. The backend PDF still prints these.
2. Action types NewDot doesn't model — supportedActionTypes is a whitelist built from CONST.REPORT.ACTIONS.TYPE. Any backend/OldDot audit action for which the App has no constant is silently dropped.

The remaining exclusions (closed-report notices, whispers targeted to others, deleted/pending-remove actions, resolved actionable whispers, NewDot REIMBURSED duplicates) are intentional UI decisions and are not bugs.

Recommended direction: This is partly a product decision, not a pure code fix — the team needs to decide which backend audit actions should appear in the NewDot history. Concretely:

• Decide whether the deprecated OldDot types above should be surfaced in the history view (they have no NewDot renderer today, so surfacing them requires message-rendering support, not just removing the blocklist entry).
• Decide whether unmodeled OldDot audit types should get a generic fallback renderer instead of being dropped by the whitelist.

If the intent is that the NewDot history is a curated chat timeline and the PDF is the complete audit record, then this may be working as designed and the fix is documentation/expectation-setting rather than code.

Investigation details

Data flow:

1. Backend syncs report actions → Onyx reportActions_<reportID>.
2. Derived value visibleReportActions precomputes visibility via shouldReportActionBeVisible — src/libs/actions/OnyxDerived/configs/visibleReportActions.ts.
3. The list is filtered for display via getSortedReportActionsForDisplay → isReportActionVisible; the expense timeline also calls it directly in MoneyRequestReportActionsList.tsx:198.
4. Actions failing any rule in shouldReportActionBeVisible are removed → UI shows fewer entries than the PDF.

All exclusion rules in shouldReportActionBeVisible: deprecated (L1244), unsupported type (L1248), MOVED_TRANSACTION from unreported report (L1253), non-"mark as closed" CLOSED (L1262), automatic TAKE_CONTROL (L1267), whispers targeted to others (L1277), PENDING_REMOVE with no visible children (L1281), actionable whispers/join-requests/card-fraud when user lacks write permission (L1285), resolved actionable whispers (L1300), NewDot REIMBURSED/MARKED_REIMBURSED duplicates (L1304), non-visible preview/money-request (L1312), and deleted/thread-parent/non-pending actions (L1316).

Confidence: High that this is client-side filtering and on the location/rules. Medium on exactly which entries are missing for the specific report in this issue — confirming that requires the affected report's raw reportActions (or an Onyx dump), which isn't attached here. The screenshots referenced in the issue live in the Slack thread only.

Not verified: whether the Web-Expensify/Auth PDF exporter includes the four deprecatedOldDotReportActions types (would confirm which category drives this specific report's discrepancy).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97354) to create a draft PR — but note the "fix" needs a product decision on which action types to surface first.
To refine: @MelvinBot <your feedback> (e.g. attach the affected report's action list so I can pinpoint the exact missing types).
To reject: Explain why you are rejecting Melvin's proposal.

[j3ffffff]

Proposal

What is the root cause of that problem?

In src/libs/ReportActionsUtils.ts, the shouldReportActionBeVisible function (starting around line 1237) applies two overlapping filters that hide legitimate OldDot-generated audit-log entries that the PDF export correctly includes:

Filter 1 – Blanket CLOSED suppression (line 1263):

if (actionName === CONST.REPORT.ACTIONS.TYPE.CLOSED && !isMarkAsClosedAction(reportAction)) {
    return false;
}

isMarkAsClosedAction (line 305–306) only returns true when the CLOSED action's originalMessage contains an amount field. OldDot generates CLOSED-type actions for many report lifecycle events (e.g. "submitted and closed", auto-pay closure, etc.) — none of these carry an amount, so every one of them is silently dropped in NewDot. The code comment explains the intent: "we're already displaying a footer that explains why the report was closed," but the PDF audit log includes every one of these events. A report that went through several submit/approve/reopen cycles will show multiple CLOSED entries in the PDF and zero in the UI.

Filter 2 – Deprecated OldDot action types (line 1137–1138):

const deprecatedOldDotReportActions = new Set([
    DELETED_ACCOUNT, REIMBURSEMENT_REQUESTED,
    REIMBURSEMENT_SETUP_REQUESTED, DONATION
]);
if (deprecatedOldDotReportActions.has(reportAction.actionName)) return true; // i.e., "is deprecated"

isReportActionDeprecated returns true for these four types, so shouldReportActionBeVisible immediately returns false for them. OldDot's audit log (and thus the PDF) includes these entries for older reports; they vanish from the NewDot UI entirely.

These two filters together explain why "many" audit-log actions appear in the PDF but not in the UI — it is a systematic suppression of OldDot-native action types, not a one-off rendering bug.

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

1. Relax the CLOSED filter: Rather than hiding every non-"mark as closed" CLOSED action, show them with appropriate message text (OldDot already provides human-readable text for each via getMessageOfOldDotReportAction). The "footer explaining closure" should remain, but the individual CLOSED audit entries should also be visible in the report history.

2. Review the deprecated-action suppression: Actions of type REIMBURSEMENT_REQUESTED, REIMBURSEMENT_SETUP_REQUESTED, DONATION, and DELETED_ACCOUNT should still be renderable when they are historical records on an existing report, even if new events of those types are no longer generated. The isReportActionDeprecated gate should only apply to actions that cannot be meaningfully displayed, not to all actions of those types.

Both changes should be confined to the shouldReportActionBeVisible logic in ReportActionsUtils.ts (lines ~1125–1317); no changes to the PDF generation path are needed.

What alternative solutions did you explore? (Optional)

• Considered whether this was a pagination/data-fetching gap (the API not returning older actions). This would explain missing items at the top of a very long history, but it would not explain why specific action types (CLOSED, REIMBURSEMENT_REQUESTED) are absent regardless of position. Code tracing confirmed these types are filtered client-side.
• Considered whether OldDot actions with empty message arrays were additionally filtered by isDeletedAction (which treats message.length === 0 as deleted). This could be a tertiary cause for some action types, but the two filters above are the dominant, systematic cause for the broad mismatch described in the issue.

[melvin-bot]

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

[melvin-bot]

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