[$250] LHN - Task badge appears in LHN when Approve action is the first required action

[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: 9.3.82-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91552
Email or phone of affected tester (no customers): jodijojosjojso@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Click Submit on the expense preview.
5. Create a task and assign it to you in workspace chat.

Expected Result:

Approve badge will persist in LHN because it is the first required action.

Actual Result:

Task badge appears in LHN when Approve action is the first required action.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7163056_1779753304418.4.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7163056

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @aimane-chnaif

[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/276da6567474e7f4b32022dbeb60c640394832bb4415a08ad99f98a9e3b2b1b5

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #91552

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

In getReasonAndReportActionThatRequiresAttention, the task badge check runs before the IOU/Approve badge check. When a chat has both an outstanding task and an expense awaiting approval:

1. getActionTypeForAssigneeToComplete is called first (line 4243). It checks report.hasOutstandingChildTask at line 4138 before checking for expenses, so it returns TASK.
2. Since the return value is truthy, the function returns early at line 4250 with a TASK badge.
3. The IOU badge logic at lines 4261-4284 — which would produce the correct APPROVE badge — is never reached.

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

Move the IOU badge check (lines 4261-4284) above the assignee-to-complete check (lines 4243-4259) in getReasonAndReportActionThatRequiresAttention. Financial actions (Submit/Approve/Pay) should take priority over Task badges since they represent the "first required action" in the workflow. This way, when an expense needs approval, the APPROVE badge is returned regardless of whether a task also exists. The TASK badge would only appear when there is no pending financial action.

What alternative solutions did you explore?

An alternative would be to compute both badges and pick the higher-priority one using a priority map. However, since the existing code already uses sequential if/return ordering to express priority, simply reordering the blocks is the minimal, consistent fix.

---

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.

[godzillaxbox19982014-lgtm]

One narrow delta to Melvin's analysis: I would avoid making Approve/Pay/Submit always outrank Task just by moving the IOU block above the task block.

The bug is specifically that getReasonAndReportActionThatRequiresAttention() returns at the task branch before it compares the task action timestamp against the earliest actionable REPORT_PREVIEW:

App/src/libs/ReportUtils.ts

Lines 4243 to 4284 in dd15fd9

	const actionTypeForAssigneeToComplete = getActionTypeForAssigneeToComplete(optionOrReport, parentReportAction);
	if (actionTypeForAssigneeToComplete) {
	const isAssigneeExpenseAction = actionTypeForAssigneeToComplete === CONST.REPORT.ACTION_TYPES_FOR_ASSIGNEE_TO_COMPLETE.EXPENSE;
	const assigneeBadge = isAssigneeExpenseAction
	? getBadgeFromIOUReport(optionOrReport, undefined, policy, optionReportMetadata, invoiceReceiverPolicy, currentUserLogin, currentUserAccountID)
	: CONST.REPORT.ACTION_BADGE.TASK;
	return {
	reason: CONST.REQUIRES_ATTENTION_REASONS.IS_WAITING_FOR_ASSIGNEE_TO_COMPLETE_ACTION,
	reportAction: Object.values(reportActions)
	.filter((action) => action.childType === CONST.REPORT.TYPE.TASK && !isTaskCompleted(action) && action.childManagerAccountID === deprecatedCurrentUserAccountID)
	// eslint-disable-next-line rulesdir/prefer-locale-compare-from-context
	.sort((a, b) => (!a.created || !b.created ? 0 : a.created.localeCompare(b.created)))
	.at(0),
	...(assigneeBadge ? {actionBadge: assigneeBadge} : {}),
	};
	}
	const {reportAction: iouReportActionToApproveOrPay, actionBadge} = getIOUReportActionWithBadge(
	optionOrReport,
	policy,
	optionReportMetadata,
	invoiceReceiverPolicy,
	currentUserLogin,
	currentUserAccountID,
	);
	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,
	};

getIOUReportActionWithBadge() already picks the earliest actionable IOU preview with isOlderReportAction():

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 323 to 363 in dd15fd9

	function getIOUReportActionWithBadge(
	chatReport: OnyxEntry<OnyxTypes.Report>,
	policy: OnyxEntry<OnyxTypes.Policy>,
	reportMetadata: OnyxEntry<OnyxTypes.ReportMetadata>,
	invoiceReceiverPolicy: OnyxEntry<OnyxTypes.Policy>,
	currentUserLogin: string,
	currentUserAccountID: number,
	): {reportAction: OnyxEntry<ReportAction>; actionBadge?: ValueOf<typeof CONST.REPORT.ACTION_BADGE>} {
	const chatReportActions = getAllReportActionsFromIOU()?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${chatReport?.reportID}`] ?? {};
	let actionBadge: ValueOf<typeof CONST.REPORT.ACTION_BADGE> | undefined;
	let earliestAction: ReportAction | undefined;
	for (const action of Object.values(chatReportActions)) {
	if (action?.actionName !== CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW || isDeletedAction(action)) {
	continue;
	}
	const iouReport = getReportOrDraftReport(action.childReportID);
	if (!iouReport) {
	// Fallback for p2p IOUs when the IOU report isn't loaded in Onyx yet (e.g. right after login).
	// Use the REPORTPREVIEW action's child* fields to determine PAY badge without the full report.
	if (chatReport?.hasOutstandingChildRequest && canPayIOUFromReportAction(action, chatReport, currentUserAccountID)) {
	if (!earliestAction || isOlderReportAction(action, earliestAction)) {
	earliestAction = action;
	actionBadge = CONST.REPORT.ACTION_BADGE.PAY;
	}
	}
	continue;
	}
	const badge = getBadgeFromIOUReport(iouReport, chatReport, policy, reportMetadata, invoiceReceiverPolicy, currentUserLogin, currentUserAccountID);
	if (badge) {
	if (!earliestAction || isOlderReportAction(action, earliestAction)) {
	earliestAction = action;
	actionBadge = badge;
	}
	}
	}
	return {reportAction: earliestAction, actionBadge};

The task branch also already sorts task child actions by created:

App/src/libs/ReportUtils.ts

Lines 4252 to 4256 in dd15fd9

	reportAction: Object.values(reportActions)
	.filter((action) => action.childType === CONST.REPORT.TYPE.TASK && !isTaskCompleted(action) && action.childManagerAccountID === deprecatedCurrentUserAccountID)
	// eslint-disable-next-line rulesdir/prefer-locale-compare-from-context
	.sort((a, b) => (!a.created || !b.created ? 0 : a.created.localeCompare(b.created)))
	.at(0),

So the smallest safe change is to build both candidates, then return the one whose reportAction.created is older. That keeps this repro as Approve because the expense preview came first, while preserving Task when the task really is the first outstanding action. A regression test should cover both orders: expense-then-task -> Approve, task-then-expense -> Task.