Unable to view report history notes in NewDot when using Copilot access

[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: 9.3.11-53
Reproducible in staging?: Y (Unable to reproduce consistently)
Reproducible in production?: Y (Unable to reproduce consistently)
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: @cristianobrocheir
Slack conversation (hyperlinked to channel name): #Epensify bugs

Action Performed:

1. Login to an account with copilot access
2. Switch to Copilot mode and select another user's account (via profile → Copilot access)
3. Navigate to a report with history/notes (approvals, edits, comments)

Expected Result:

Report history notes should load and display correctly for admins in Copilot mode, matching the behavior when viewing the same reports from their own admin account and matching Expensify Classic.

Actual Result:

In Copilot mode, the report history shows only a persistent loading skeleton (no content loads). Notes are visible when the admin views the same report from their own account, and visible in Expensify Classic.

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

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @hoangzinh

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @lydiabarclay (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.

[Harmatta]

Proposal

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

When using Copilot access (delegate mode) to view another user's account, navigating to a report shows a persistent loading skeleton for the report history/notes. The content never loads. The same report displays correctly when viewed from the user's own account and in Expensify Classic.

What is the root cause of that problem?

The report action fetching functions (getOlderActions and getNewerActions in src/libs/actions/Report.ts) do not include the delegateAccountID parameter when constructing the API request. When a Copilot/delegate views a report, the backend needs the delegate account context to authorize fetching the report's historical actions. Without this parameter, the API cannot properly resolve permissions for the delegated account, causing the request to fail silently and leaving the loading skeleton displayed indefinitely.

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

1. Modify getOlderActions() and getNewerActions() in src/libs/actions/Report.ts to accept and pass through the delegateAccountID parameter when constructing the API request parameters for GET_OLDER_ACTIONS and GET_NEWER_ACTIONS.
2. Update the API parameter types (GetOlderActionsParams and GetNewerActionsParams) in the relevant types file to include the optional delegateAccountID field.
3. Update the call sites in the report rendering components (e.g., ReportActionsListItemRenderer.tsx and related report view components) to extract the current delegateAccountID from the session/delegate context and pass it when invoking the report action fetch functions.

This mirrors the pattern already used in other parts of the codebase where delegateAccountID is passed for delegate-aware API calls.

What alternative solutions did you explore? (Optional)

An alternative would be to inject the delegateAccountID at the API middleware/interceptor level so all API calls automatically include it when in delegate mode. However, this is a broader change with higher risk. The targeted fix to getOlderActions/getNewerActions is more surgical and consistent with how other delegate-aware calls are handled in the codebase.

[Harmatta]

Update — code verification:

I dug into the actual source to verify the root cause. Here's what I found:

1. Confirmed: API parameters lack delegateAccountID

src/libs/API/parameters/GetOlderActionsParams.ts:

type GetOlderActionsParams = {
    reportID: string;
    reportActionID: string;
};

src/libs/API/parameters/GetNewerActionsParams.ts has the identical shape — only reportID and reportActionID, no delegate context.

2. delegateAccountID exists in the codebase but never reaches the API layer

• src/libs/ReportActionsUtils.ts has getDelegateAccountIDFromReportAction() — this extracts delegate info FROM actions, but nothing passes it INTO fetch requests.
• A code search for delegateAccountID across src/libs/API/parameters/ returns zero files. No API parameter type includes it.

3. Fix path (specific)

• Add optional delegateAccountID?: number to both GetOlderActionsParams and GetNewerActionsParams in src/libs/API/parameters/.
• In src/libs/actions/Report.ts, populate it from the current delegate session state when calling API.read(READ_COMMANDS.GET_OLDER_ACTIONS, ...) and API.read(READ_COMMANDS.GET_NEWER_ACTIONS, ...).
• The delegate state is available via DelegateModule or the Onyx session store depending on the current delegate context pattern used elsewhere.

[melvin-bot]

@hoangzinh @lydiabarclay this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@hoangzinh 12 days overdue. Walking. Toward. The. Light...

[lydiabarclay]

@hoangzinh can you please review here?