Fix: use server-rendered message for moved-report action when destination policy is unavailable locally by MelvinBot · Pull Request #98238 · Expensify/App

MelvinBot · 2026-08-11T03:32:37Z

Explanation of Change

The workspace name in the "moved this report to the … workspace" system message was recomputed on every render from the current user's local Onyx policy collection, with a bare empty-string fallback:

const toPolicyName = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${toPolicyID}`]?.name ?? '';

When User A is not a member of the destination workspace and never opened it, policy_<toPolicyID> isn't in their Onyx, so the lookup returns '' and the message renders with a blank name. It only appeared later because creating another expense delivered that policy into User A's COLLECTION.POLICY, after which the message re-rendered correctly.

This change makes getMovedActionMessage fall back to the server-rendered action message (getReportActionHtml(action)) when the destination policy isn't available locally (so toPolicyName would be empty). The broadcast action already carries the name the server rendered, so User A sees it immediately. When the policy is present locally, the current live-computed string is kept so nothing else changes. This mirrors the existing pattern where messages fall back to the stored action text when their computed inputs aren't available. Returning the stored HTML covers both consumption paths — the HTML-rendered report view and the plain-text LHN/preview callers that wrap the result in Parser.htmlToText(...).

A unit test was added covering the fallback path (destination policy absent locally → stored action HTML returned).

Fixed Issues

$ #98108
PROPOSAL: #98108 (comment)

Tests

Sign in as User A.
Create a manual expense for User B.
As User B, open the expense report and select Pay → Pay with business account.
Cancel the bank-account setup and verify the expense moves to User B’s workspace.
As User A, open the DM with User B without opening the workspace chat.
Verify the moved-report message and LHN preview immediately show the workspace name.

Verify that no errors appear in the JS console

Offline tests

Complete the tests above.
Enable Force offline.
Navigate away and reopen the DM.
Verify the moved-report message and LHN preview still show the workspace name.
Disable Force offline.

QA Steps

Same as Tests and Offline tests.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android-pr98238.mp4

Android: mWeb Chrome

Android-mWeb-pr98238.mp4

iOS: Native

ios-pr98238.mp4

iOS: mWeb Safari

ios-mWeb-pr98238.mp4

MacOS: Chrome / Safari

Chrome-pr98238.mp4

…tion policy is unavailable locally Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>

…s live Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>

MelvinBot · 2026-08-11T03:43:53Z

Fixed the failing check. Pushed 2f4ce0b.

What was failing: test (job 5) → ReportActionItem › System notification actions › MOVED action renders moved message at tests/ui/ReportActionItemTest.tsx:1585.

Root cause (directly from this PR's change): the test's MOVED action uses toPolicyID: 'policy1', which is never added to Onyx. The new fallback in getMovedActionMessage now returns the stored action HTML whenever the destination policy is absent locally. The shared createReportAction test helper stubs message as 'some message', so the action rendered some message instead of the live-computed "moved this…" text, failing the /moved this/i assertion.

Fix: seed policy1 into Onyx in that test (mirroring the existing MODIFIED_EXPENSE test) so it exercises the member/live-computed path and renders the real moved message. No production code changed.

Other non-passing checks (not addressed — not code failures)

build (Expensify Dev, Debug, true) — infra failure, unrelated to this PR. The iOS Rock remote build failed installing CocoaPods deps: Error installing React-Core-prebuilt → curl: (56) The requested URL returned error: 401. This is a prebuilt-artifact download auth issue in CI, not something in the diff. It should clear on re-run.
checklist and Check independent approval — these are the standard author/approval checklist gates, not CI test failures.

MelvinBot · 2026-08-11T03:49:12Z

The real failure is already fixed by my earlier push (2f4ce0b). Re-running the checks confirms it:

All 8 test jobs now pass, including the previously-failing test (job 5) (MOVED action renders moved message).
typecheck and the iOS build both pass (the earlier build failure was a transient CI CocoaPods 401, now cleared).

The only checks still showing as failed are checklist and Check independent approval — these are the standard PR author-checklist / approval gates, not CI test failures, and require human action (completing the checklist / getting an independent review). Nothing further for me to fix here.

MelvinBot · 2026-08-11T03:52:01Z

The code-related failures are resolved by my earlier push (2f4ce0b) — all 8 test (job N) shards now pass, including test (job 5) which was the real failure.

The only checks still red are checklist and Check independent approval. These aren't CI/test failures — they're the standard PR-author checklist and independent-approval gates, which need human action (complete the checklist items / obtain an independent reviewer's approval). There's nothing for me to push here.

nyomanjyotisa · 2026-08-11T14:27:03Z

Updated PR description