[$250] Approval reports were not visible in the app when the approver received approval notification emails

[izarutskaya]

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 (missing details)
Reproducible in production?: Needs reproduction (missing details)
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: @rickbalut
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Customer received an approval request email for a report.
2. Customer opened Expensify to review pending approvals.
3. The report requiring approval was not visible in the app.
4. For one report, the customer had to open the report through the email link.
5. For another report, the customer had to refresh and navigate through the app multiple times before the report appeared.

Expected Result:

Reports requiring approval should immediately appear in the approver's inbox/workspace when the approval notification email is sent, without requiring page refreshes or opening the report from the email link.

Actual Result:

Reports requiring approval did not appear in the app initially despite approval notification emails being received. The reports only became visible after opening the email link or repeatedly refreshing the application.

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

For the customer details check please the OP.

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062223339583071941
• Upwork Job ID: 2062223339583071941
• Last Price Increase: 2026-06-10

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Issue Analysis

⚠️ Medium confidence — the symptom pattern is a strong tell, but there are no reportIDs, logs, or a version number on this issue, so this can't be confirmed against production yet.

Root cause (most likely): This is a real-time data-sync gap, not a rendering bug. When a report is routed to an approver, the live Pusher "Onyx update" that lands on the approver's client appears to be missing one or more of the fields the LHN strictly requires to show a row. The App's sidebar filtering then silently drops the report until a full OpenApp/ReconnectApp (i.e. a refresh) returns the fully-hydrated snapshot — which is exactly why refreshing, or opening the report via the email deep-link (which fires an OpenReport fetch), made it appear.

Where the fix likely lives: The fields that gate visibility (hasOutstandingChildRequest on the parent chat, the parent chat's REPORT_PREVIEW action, a complete report skeleton, a non-hidden notificationPreference) are populated on the approver's side only when the backend includes them in the live update. That points to a backend (Auth / Web-Expensify) push-payload completeness issue, which is outside the Expensify/App repo. An internal engineer with backend access should verify the live update sent at approval-email time and compare it against the full OpenApp snapshot. I'm not proposing an App-side code change because the App-side filtering is behaving as designed.

Investigation details — the App-side LHN gates (public code) and why they'd hide a partially-synced report

The LHN visibility decision runs useSidebarOrderedReports → SidebarUtils.getReportsToDisplayInLHN → shouldDisplayReportInLHN → reasonForReportToBeInOptionList.

Gates that can drop a freshly-pushed-but-incomplete report:

• Strict skeleton check — a report missing reportID, type, reportName, or participants is rejected (ReportUtils.ts:9591-9608). An incremental update that merges only lastMessageText/lastVisibleActionCreated onto a non-existent record would fail this until a full refresh.
• Hidden parent chat — a chat with notificationPreference: 'hidden' is hidden unless overridden by requiresAttention / draft / pin (SidebarUtils.ts:327-339).
• "Needs my approval" signal — the green-dot inclusion comes from requiresAttention → HAS_CHILD_REPORT_AWAITING_ACTION, which fires only if the parent chat has hasOutstandingChildRequest === true (getOutstandingChildRequest, ReportUtils.ts:11649-11672) or a discoverable REPORT_PREVIEW/IOU action (ReportUtils.ts:4210-4359). If the live update omits hasOutstandingChildRequest or the reportActions_* preview, an otherwise-empty chat gets hidden.
• Reactivity — reportAttributes (where requiresAttention lives) only recomputes when a listened-to field changes (useSidebarOrderedReports.tsx:183-245), so a partial push may not even trigger a re-evaluation.

Alternative explanation considered: a pure App-side filtering bug (the report is fully in Onyx but a gate wrongly rejects it). This is less likely because a full refresh fixes it — if the data were complete, the same gates would pass before the refresh too. The "fixed by refresh / deep-link" behavior specifically implicates missing data in the incremental path.

To confirm (needs production evidence): for one affected approver+report at email-send time — (1) was a live Onyx update emitted, and did it carry the IOU report's full skeleton, the parent chat's hasOutstandingChildRequest, and the reportActions_<chatReportID> REPORT_PREVIEW? (2) what was the parent chat's notificationPreference before vs. after OpenApp?

Possibly related: #91320 ("Unread DM from Managed Customer Not Surfacing in LHN — Only Visible via Search/Email Notification") shows the same shape — an incremental update arrives but the row doesn't surface in the LHN until a refresh/search.

---

Next Steps for Contributor+ team:
To refine: @MelvinBot <your feedback> (e.g. share a reportID + approximate timestamp and I'll have logs checked).
Note: Since the likely fix is backend (outside Expensify/App), this should be escalated to an internal engineer with Auth/Web-Expensify access to verify the live update payload before any App-side work is considered.

[melvin-bot]

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

[melvin-bot]

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

[yusufdeveloper2903]

Proposal

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

When an approver receives the email saying a report is waiting on them to approve, that report does not appear in their NewDot inbox/workspace in real time. It only becomes visible after they open the report from the email deep link, or after refreshing/navigating around the app several times.

What is the root cause of that problem?

NewDot's LHN is purely data-driven — a report shows up the instant its Onyx data is present and passes reasonForReportToBeInOptionList, and disappears/never shows when that data is absent. There is no separate "fetch my pending approvals" poll; the inbox is just a projection of what's in Onyx. So a report that is "invisible until I open it / refresh" is the classic signature of the approver's client never receiving the real-time Onyx update for that report — the data only lands later, when a backfill command runs.

Here's the chain, traced in code:

1. The approver's GBR / "needs approval" surfacing depends on data the approver only gets from the server. Whether the expense (and its parent workspace chat) light up as "waiting on you" is decided by getReasonAndReportActionThatRequiresAttention, which keys off hasOutstandingChildRequest and the IOU report action on the report:

https://github.com/Expensify/App/blob/8020a9338e8/src/libs/ReportUtils.ts#L4283-L4326

That in turn drives the LHN inclusion reason here:

https://github.com/Expensify/App/blob/8020a9338e8/src/libs/ReportUtils.ts#L9647-L9655

2. When the submitter submits, the manager-facing state is set as optimistic data — which is applied to the submitter's Onyx only, never the approver's. In submitReport, hasOutstandingChildRequest is written optimistically on the parent report, and the whole thing is sent via API.write(SUBMIT_REPORT, …):

https://github.com/Expensify/App/blob/8020a9338e8/src/libs/actions/IOU/ReportWorkflow.ts#L1425-L1436

https://github.com/Expensify/App/blob/8020a9338e8/src/libs/actions/IOU/ReportWorkflow.ts#L1555-L1562

Optimistic data is local to the actor (the submitter). The approver's copy of that report/parent-chat/report-action can only arrive through a server-pushed Onyx update broadcast to the approver's account.

3. The approver receives that update over Pusher, and the only safety net for a dropped update is gap-detection — which itself needs a later event to fire. Real-time updates come in through the Pusher multipleEvents handler:

https://github.com/Expensify/App/blob/8020a9338e8/src/libs/actions/User.ts#L931-L950

which calls applyOnyxUpdatesReliably. The gap check only re-fetches missing updates when an update actually arrives whose previousUpdateID doesn't line up with the client's last applied ID:

https://github.com/Expensify/App/blob/8020a9338e8/src/libs/actions/applyOnyxUpdatesReliably.ts#L43-L53

So if the SUBMIT_REPORT broadcast to the approver's account is never delivered (or is dropped before being applied), there is nothing to expose the gap. The report stays missing until some other path backfills it:

• Opening the email link → OpenReport fetches the report + its actions directly → it appears. ✅ (matches "had to open it through the email link")
• Refresh / app foreground → ReconnectApp / GetMissingOnyxUpdates pulls everything since the last lastUpdateID → it appears. ✅ (matches "refresh and navigate multiple times before it appeared")

This is exactly the reported behaviour. The frontend rendering path is working as designed — it faithfully shows whatever is in Onyx — which is why the only two ways it "appears" are the two backfill commands, not a re-render.

Most likely root cause: the real-time SUBMIT_REPORT Onyx-update broadcast to the manager/approver's account is not reliably reaching their client. The strongest suspects, in order:

1. Backend (most likely): the SUBMIT_REPORT (and/or the approver-routing path when the report is force-submitted / re-routed through a workflow) doesn't include the approver in the broadcast accountIDList, so no Pusher update is pushed to them at submit time. This fits "Reproducible in staging?/production?: unable to reproduce" — it's timing/routing dependent, not deterministic from the UI.
2. Web client delivery (secondary): the Pusher handler only processes updates on the leader tab (ActiveClientManager.isClientTheLeader() guard at User.ts#L934). On Windows: Chrome (the only platform checked in the report), a backgrounded/throttled leader tab can have its websocket suspended, so the push is missed and only recovered on the next foreground ReconnectApp.

I cannot prove suspect #1 from the App repo alone (the broadcast recipient list lives in Web-Expensify/Auth), so I'm being explicit that this is a server-side delivery issue rather than a NewDot rendering bug — the App code above is the evidence that the client can only show what it's been sent.

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

The fix belongs where the data delivery breaks, so the first step is to confirm whether the approver's client ever receives a Pusher update at submit time:

1. Have the submitter submit a report to an approver who is online with NewDot open, and on the approver's session capture the logs around the expected moment. If there is no [subscribeToUserEvents] Applying Onyx updates / onyxApiUpdate entry carrying the new reportID, the update was never broadcast → backend fix: ensure SUBMIT_REPORT (and the approver-routing/force-submit path) broadcasts the report, its parent workspace chat (hasOutstandingChildRequest: true), the REPORT_PREVIEW/SUBMITTED report action, and the next-step to the approver's accountID, with correctly chained previousUpdateID/lastUpdateID so gap-detection can self-heal if a single event is dropped.

2. If the update is received but the report still doesn't surface, the bug is on the client and I'd debug reasonForReportToBeInOptionList for that report (e.g. the empty-report guard hiding a total === 0, submitted, CREATED-only report at ReportUtils.ts#L9641-L9645).

3. For the web/leader-tab angle, verify by reproducing with a single foreground tab vs. a backgrounded leader tab. If a throttled leader tab is the cause, the defensive client fix is to make sure a visibility/foreground ReconnectApp reliably runs and re-applies missed updates when a previously-backgrounded tab regains focus, so the inbox self-heals without manual refreshes.

I'm intentionally not posting a speculative frontend diff: the rendering code is correct and a change there would mask, not fix, the missing-broadcast root cause. The actionable next step is the targeted log capture above to localize the drop to the backend broadcast (suspect #1) vs. web leader-tab delivery (suspect #2).

What alternative solutions did you explore? (Optional)

• Add a client-side poll for pending approvals. Rejected — it contradicts the offline-first, Onyx-update-driven architecture, adds load, and only papers over a dropped broadcast.
• Loosen reasonForReportToBeInOptionList so submitted reports always show. Rejected — the report genuinely isn't in the approver's Onyx yet, so there's nothing for the filter to let through; loosening it would only risk showing half-loaded reports elsewhere.

[oqildev]

What is the root cause of that problem?

NewDot can only learn that a report exists through three channels: a real-time Pusher onyx update on the user's private channel, an OpenReport call (deeplink/opening the chat), or an OpenApp/ReconnectApp snapshot (cold start / refresh). The LHN never invents reports — SidebarUtils.getReportsToDisplayInLHN only iterates the reports collection that already lives in Onyx:

App/src/libs/SidebarUtils.ts

Lines 367 to 393 in c07f8e4

	for (const [reportID, report] of Object.entries(allReportsDictValues)) {
	if (!report) {
	continue;
	}
	const reportDraftComment = draftComments?.[`${ONYXKEYS.COLLECTION.REPORT_DRAFT_COMMENT}${report.reportID}`];
	const {shouldDisplay, hasErrorsOtherThanFailedReceipt} = shouldDisplayReportInLHN({
	report,
	reports,
	currentReportId,
	isInFocusMode,
	betas,
	transactionViolations,
	draftComment: reportDraftComment,
	transactions,
	isOffline,
	isReportArchived: isArchivedReport(reportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`]),
	reportAttributes,
	});
	if (shouldDisplay) {
	const requiresAttention = reportAttributes?.[report?.reportID]?.requiresAttention ?? false;
	const hasAttentionOrError = requiresAttention || hasErrorsOtherThanFailedReceipt;
	reportsToDisplay[reportID] = hasAttentionOrError ? {...report, requiresAttention, hasErrorsOtherThanFailedReceipt} : report;
	}
	}

And the approval row is purely data-driven. An approver's workspace chat surfaces a green dot only because requiresAttentionFromCurrentUser finds an outstanding child request / a REPORT_PREVIEW action awaiting approve-or-pay on the report — both server-set fields:

App/src/libs/ReportUtils.ts

Lines 4257 to 4274 in c07f8e4

	const {reportAction: iouReportActionToApproveOrPay, actionBadge} = getIOUReportActionWithBadge(optionOrReport, policy, optionReportMetadata, invoiceReceiverPolicy);
	const iouReportID = getIOUReportIDFromReportActionPreview(iouReportActionToApproveOrPay);
	const transactions = getReportTransactions(iouReportID);
	const hasOnlyPendingTransactions = transactions.length > 0 && transactions.every((t) => isExpensifyCardTransaction(t) && isPending(t));
	// Has a child report that is awaiting action (e.g. approve, pay, add bank account) from current user
	const hasStaleChildRequest = isTripRoom(optionOrReport) && (optionOrReport.transactionCount ?? 0) === 0;
	if (
	((optionOrReport.hasOutstandingChildRequest === true && !hasStaleChildRequest) || iouReportActionToApproveOrPay?.reportActionID) &&
	(policy?.reimbursementChoice !== CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO || !hasOnlyPendingTransactions)
	) {
	return {
	reason: CONST.REQUIRES_ATTENTION_REASONS.HAS_CHILD_REPORT_AWAITING_ACTION,
	reportAction: iouReportActionToApproveOrPay,
	actionBadge,
	};
	}

…which is what then forces it into the list regardless of view mode:

App/src/libs/ReportUtils.ts

Lines 9586 to 9588 in c07f8e4

	if (requiresAttention ?? requiresAttentionFromCurrentUser(report, undefined, isReportArchived)) {
	return CONST.REPORT_IN_LHN_REASONS.HAS_GBR;
	}

So if report / its REPORT_PREVIEW action / hasOutstandingChildRequest aren't in Onyx, there is nothing to render — reasonForReportToBeInOptionList bails out the moment the report has no type/reportName/participants:

App/src/libs/ReportUtils.ts

Lines 9520 to 9541 in c07f8e4

	// Exclude reports that have no data because there wouldn't be anything to show in the option item.
	// This can happen if data is currently loading from the server or a report is in various stages of being created.
	// This can also happen for anyone accessing a public room or archived room for which they don't have access to the underlying policy.
	// Optionally exclude reports that do not belong to currently active workspace
	if (
	!report?.reportID ||
	!report?.type ||
	report?.reportName === undefined ||
	(!report?.participants &&
	// We omit sending back participants for chat rooms when searching for reports since they aren't needed to display the results and can get very large.
	// So we allow showing rooms with no participants–in any other circumstances we should never have these reports with no participants in Onyx.
	!isChatRoom(report) &&
	!isChatThreadReport &&
	!isReportArchived &&
	!isMoneyRequestReport(report) &&
	!isTaskReport(report) &&
	!isSelfDMReport &&
	!isSystemChatReport &&
	!isGroupChat(report))
	) {
	return null;
	}

Now line up the two recoveries the customer described. Opening the report from the email link is a deeplink that runs openReport, which fetches that report + its actions from the server:

App/src/libs/actions/Report/index.ts

Lines 1264 to 1268 in c07f8e4

	function openReport(params: OpenReportActionParams) {
	const {
	reportID,
	introSelected,
	reportActionID,

Refreshing the page runs reconnectApp, which pulls a fresh snapshot of the report list:

App/src/libs/actions/App.ts

Lines 465 to 476 in c07f8e4

	function reconnectApp(updateIDFrom: OnyxEntry<number> = 0) {
	const bootsplashSpan = getSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.ROOT);
	if (bootsplashSpan) {
	startSpan(CONST.TELEMETRY.SPAN_NAVIGATION.APP_OPEN, {
	name: CONST.TELEMETRY.SPAN_NAVIGATION.APP_OPEN,
	op: CONST.TELEMETRY.SPAN_NAVIGATION.APP_OPEN,
	parentSpan: bootsplashSpan,
	});
	}
	hasLoadedAppPromise.then(() => {

Both fixes are server fetches. That's the tell: the data wasn't filtered out of the LHN, it was absent from Onyx entirely until a fetch pulled it in. The only way that happens is the channel that should have delivered it in real time — the targeted Pusher onyx update to the approver's account when the report is submitted/forwarded to them — didn't reach this session.

The App's own safety net doesn't save this case either. OnyxUpdateManager detects a missed update and back-fills it, but only when a later Pusher update arrives carrying a previousUpdateID ahead of the client's lastUpdateIDAppliedToClient:

App/src/libs/actions/OnyxUpdateManager/index.ts

Lines 178 to 193 in c07f8e4

	if (areDeferredUpdatesQueued || isFetchingForPendingUpdates) {
	return false;
	}
	console.debug(`[OnyxUpdateManager] Client is fetching missing updates from the server, from updates ${lastUpdateIDFromClient} to ${Number(previousUpdateIDFromServer)}`);
	Log.info('Gap detected in update IDs from the server so fetching incremental updates', true, {
	lastUpdateIDFromClient,
	lastUpdateIDFromServer,
	previousUpdateIDFromServer,
	});
	// Get the missing Onyx updates from the server and afterwards validate and apply the deferred updates.
	// This will trigger recursive calls to "validateAndApplyDeferredUpdates" if there are gaps in the deferred updates.
	setMissingOnyxUpdatesQueryPromise(getMissingOnyxUpdates(lastUpdateIDFromClient, previousUpdateIDFromServer).then(() => validateAndApplyDeferredUpdates(clientLastUpdateID)));
	return true;

For an idle approver who just opened the app and isn't generating traffic, no subsequent update arrives to expose the gap, so the missing approval report stays invisible until the next manual ReconnectApp (refresh) or OpenReport (email link) — exactly the workaround pattern in the report.

So the root cause isn't in App code: the submit/forward-for-approval write on the backend (Auth) isn't reliably including the new approver among the onyx-update push recipients. NewDot renders correctly the instant that data lands; it just never gets told.

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

This is a backend (Auth) push-targeting fix, not an App one. When a report transitions to SUBMITTED/forwarded and a (possibly new) approver becomes the managerID, the write must push the resulting onyx updates — the expense report, the workspace chat's REPORT_PREVIEW action, and hasOutstandingChildRequest on the approver's chat — to the approver's private channel, not just the submitter's. I'd route this issue to the Auth team and ask them to confirm the approver is in the push recipient set for SubmitReport/ApproveReport/the auto-submit (workflow) path. I don't think there's a layer in this repo to change — the LHN/GBR logic above already does the right thing once the data exists, and the offline-first contract is that the server pushes the writer's and the affected approver's onyx deltas.

If we want an App-side mitigation while the backend is sorted, the only honest lever is freshness of the snapshot — e.g. firing a ReconnectApp on app foreground/visibility-change so an idle approver re-syncs sooner. I'd treat that as a band-aid, not the fix, since it doesn't close the real-time gap and adds load.

What alternative solutions did you explore? (Optional)

H2 — stale LHN memoization (App-side). The thought: data was pushed, but useSidebarOrderedReports/getReportsToDisplayInLHN didn't recompute, so the row only appeared after navigating around forced re-renders. Rejected: a page refresh rebuilds the ordered list from scratch over the entire reports collection on first render (

App/src/libs/SidebarUtils.ts

Lines 367 to 393 in c07f8e4

	for (const [reportID, report] of Object.entries(allReportsDictValues)) {
	if (!report) {
	continue;
	}
	const reportDraftComment = draftComments?.[`${ONYXKEYS.COLLECTION.REPORT_DRAFT_COMMENT}${report.reportID}`];
	const {shouldDisplay, hasErrorsOtherThanFailedReceipt} = shouldDisplayReportInLHN({
	report,
	reports,
	currentReportId,
	isInFocusMode,
	betas,
	transactionViolations,
	draftComment: reportDraftComment,
	transactions,
	isOffline,
	isReportArchived: isArchivedReport(reportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`]),
	reportAttributes,
	});
	if (shouldDisplay) {
	const requiresAttention = reportAttributes?.[report?.reportID]?.requiresAttention ?? false;
	const hasAttentionOrError = requiresAttention || hasErrorsOtherThanFailedReceipt;
	reportsToDisplay[reportID] = hasAttentionOrError ? {...report, requiresAttention, hasErrorsOtherThanFailedReceipt} : report;
	}
	}

). If the data were already present, refresh alone would surface it immediately — but the customer additionally needed the email link / repeated navigation, which is consistent with a fetch, not a recompute.

H3 — report pushed but hidden (App-side filter). The thought: the approver's chat arrives with notificationPreference: hidden and gets filtered. Rejected: shouldDisplayReportInLHN explicitly overrides hidden status when the report requiresAttention (

App/src/libs/SidebarUtils.ts

Lines 316 to 331 in c07f8e4

	// Check if report should override hidden status
	const requiresAttention = reportAttributes?.[report?.reportID]?.requiresAttention;
	const isSystemChat = isSystemChatUtil(report);
	const shouldOverrideHidden =
	!!draftComment ||
	hasErrorsOtherThanFailedReceipt ||
	isFocused ||
	isSystemChat ||
	!!report.isPinned ||
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	requiresAttention ||
	(report.isOwnPolicyExpenseChat && !isReportArchived);
	if (isHidden && !shouldOverrideHidden) {
	return {shouldDisplay: false};
	}

). An approval report whose data is present would set requiresAttention, so a hidden flag wouldn't keep it out of the LHN — which again points to the data being absent rather than suppressed.

Note: this is labeled Needs Reproduction with no Version Number and "unable to reproduce" on staging/prod. The analysis above identifies why the symptom occurs given the architecture, but confirming it will require Auth-side logs of the submit/approve push recipients for the affected approver from the linked Slack thread, since the failure is in what the server pushed, not in what the client did with it.

[moxw]

Proposal

What is the root cause of that problem?

The LHN decides whether an approval report is visible from reportAttributes.requiresAttention, which comes from getIOUReportActionWithBadge() / canApproveIOU().

For approval reports, canApproveIOU() requires the child report transactions to already be loaded. But when the approver first receives the approval notification, the app can have the parent policy expense chat / report preview metadata before it has the full child transaction collection. In that state the report preview already has enough child metadata to identify an approval action, but we only have a preview fallback for PAY (canPayIOUFromReportAction()), not for APPROVE.

So the approval badge is not produced, requiresAttention stays false, hidden/empty policy expense chats are not forced into the LHN, and the report only appears after opening the email deep link or refreshing because those paths hydrate the full report/transactions.

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

Add an approval fallback next to the existing pay fallback in src/libs/actions/IOU/ReportWorkflow.ts.

Specifically:

1. Add a helper like canApproveIOUFromReportAction(action, policy, currentUserAccountID) that uses the report preview child fields when the child report/transactions are not hydrated yet:

   • current user matches childManagerAccountID
   • child state/status is submitted and not approved/closed/reimbursed
   • childMoneyRequestCount > 0
   • policy is a paid group policy and not submit-and-close
   • action is not deleted / pending delete

2. In getIOUReportActionWithBadge(), keep the existing canApproveIOU() path when the child report and transactions are loaded, but if they are missing or empty, use the preview fallback to return CONST.REPORT.ACTION_BADGE.APPROVE.

3. Reuse the same fallback in hasOutstandingChildRequest() so recomputing the parent policy expense chat does not depend on opening the child report first.

4. Add tests for:

   • a policy expense chat with a submitted child preview assigned to the current user but no loaded transactions still returns the APPROVE badge
   • approved/reimbursed/closed child preview states do not show APPROVE
   • when transactions are loaded, the existing canApproveIOU() behavior still wins, including pending/scanning-only transaction exclusions

What alternative solutions did you explore? (Optional)

We could force an OpenReport or full ReconnectApp after receiving approval-related updates, or require the backend to always include the full child transaction set with the notification/update. That would work around the symptom, but it is heavier and still leaves the LHN brittle when it already has enough report-preview metadata to know that the approver has an actionable report.