[$250] Expense - No error displayed after update the Onyx to add a brokenCardConnection

[nlemma]

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.4.15-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Expensify/issues/565029
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows Windows 11 - Chrome

Action Performed:

1. Log in to the app as User A.
2. Create a new workspace and add User B as a member.
3. Log in as User B, submit an expense in this workspace, and note its transactionId.
4. As User A, go to the workspace, navigate to Workflows, and set the frequency to Instantly.
5. As User A, open the expense submitted by User B.
6. Manually update the Onyx data to add a brokenCardConnection violation to the transaction. For example:

Onyx.set(`transactionViolations_YOUR_TRANSACTION_ID`, [{
   type: 'warning',
   name: 'rter',
   data: {rterType: 'brokenCardConnection'},
}]);

Expected Result:

"Receipt pending due to broken bank connection. Please resolve in Company cards." message displayed

Actual Result:

no "Receipt pending due to broken bank connection. Please resolve in Company cards." message displayed. RBR only shown on expense preview

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164478_1779902557090.1779219660401_no_msg.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067922858847246640
• Upwork Job ID: 2067922858847246640
• Last Price Increase: 2026-07-03

[MelvinBot]

Proposal

What is the root cause of that problem?

isPersonalCard(undefined) returns true, which causes the broken-connection status message to be suppressed whenever the violation has no resolvable card.

In MoneyRequestHeader.tsx:122-141, the status bar is built like this:

const cardID = brokenConnectionError?.data?.cardID;          // undefined in the repro
const card = cardID ? cardList?.[cardID] : undefined;        // undefined
const isBrokenPersonalCard = isPersonalCard(card);           // isPersonalCard(undefined) === true

if (isBrokenPersonalCard && brokenConnectionError) {
    return undefined;                                        // ← message suppressed
}

The violation added in the repro has no cardID in its data, so card resolves to undefined. isPersonalCard is:

function isPersonalCard(card?: Card) {
    return !card?.fundID || card.fundID === '0' || card?.bank === CONST.PERSONAL_CARDS.BANK_NAME.CSV;
}

For card === undefined, !card?.fundID evaluates to !undefined → true. So an absent card is misclassified as a personal card, the early return undefined fires, and the expected adminBrokenConnectionError message ("Receipt pending due to broken bank connection. Please resolve in Company cards.") never renders. The violation itself still exists, which is why the RBR indicator still shows on the expense preview — matching the reported "RBR only shown on expense preview".

Why the gate is reached / evidence the message should show

• The viewer (User A) is the policy admin and not the submitter, the report is processing, and instant submit is enabled, so shouldShowBrokenConnectionViolation returns true (isProcessingReport && isInstantSubmitEnabled).
• The admin-path string is adminBrokenConnectionError, rendered by BrokenConnectionDescription.tsx:42-44 — exactly the expected text.
• The personal-card early-return was intended to suppress the standard message only for actual personal-card broken connections; it should not fire when no card is resolvable.

Caveat: the repro injects the violation manually with no cardID. The defect (isPersonalCard(undefined) === true) is real and confirmed in code, but how often a real backend brokenCardConnection violation arrives without a resolvable cardID (e.g. card not yet in cardList, or company-card violation missing cardID) was not verified against production logs. The fix is correct defensively regardless.

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

Only treat the violation as a personal-card connection when a card actually resolves. In MoneyRequestHeader.tsx:126, guard on the card existing before calling isPersonalCard — i.e. require a non-empty card so that an unresolved card no longer suppresses the message. With that guard, the admin (no card resolved) falls through to the BrokenConnectionDescription branch and the expected message renders.

Optionally, also harden isPersonalCard to return false for a missing card, but other callers may rely on current behavior, so prefer fixing it at the call site in MoneyRequestHeader.

What alternative solutions did you explore? (Optional)

None — the call-site guard is the minimal, targeted fix.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94022) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-19 10:51:28 UTC.

Proposal

What is the root cause of that problem?

The broken-connection status message is rendered by the expense header status bar. For a single expense it comes from MoneyRequestHeader, where the BROKEN_CONNECTION branch resolves the card from the violation's cardID and bails out early if it considers the card a "broken personal card":

App/src/components/MoneyRequestHeader.tsx

Lines 122 to 140 in d81cc58

	if (!!transaction?.transactionID && !!transactionViolations.length && shouldShowBrokenConnectionViolation) {
	const brokenConnectionError = transactionViolations?.find((violation) => violation.data?.rterType === CONST.RTER_VIOLATION_TYPES.BROKEN_CARD_CONNECTION);
	const cardID = brokenConnectionError?.data?.cardID;
	const card = cardID ? cardList?.[cardID] : undefined;
	const isBrokenPersonalCard = isPersonalCard(card);
	if (isBrokenPersonalCard && brokenConnectionError) {
	return undefined;
	}
	return {
	icon: getStatusIcon(expensifyIcons.Hourglass),
	description: (
	<BrokenConnectionDescription
	transactionID={transaction?.transactionID}
	report={parentReport}
	policy={policy}
	/>
	),
	};

const cardID = brokenConnectionError?.data?.cardID;
const card = cardID ? cardList?.[cardID] : undefined;
const isBrokenPersonalCard = isPersonalCard(card);

if (isBrokenPersonalCard && brokenConnectionError) {
    return undefined; // <- suppresses the status message
}

The problem is isPersonalCard returns true for an undefined card:

App/src/libs/CardUtils.ts

Lines 1536 to 1538 in d81cc58

	function isPersonalCard(card?: Card) {
	return !card?.fundID || card.fundID === '0' || card?.bank === CONST.PERSONAL_CARDS.BANK_NAME.CSV;
	}

function isPersonalCard(card?: Card) {
    return !card?.fundID || card.fundID === '0' || card?.bank === CONST.PERSONAL_CARDS.BANK_NAME.CSV;
}

With card === undefined, !card?.fundID evaluates to !undefined === true, so isPersonalCard(undefined) is true.

In this scenario the injected rter/brokenCardConnection violation carries no cardID (and the real backend violation for a company-card broken connection has no resolvable personal card either), so card is undefined → isBrokenPersonalCard is true → brokenConnectionError is truthy → the branch hits return undefined and the status bar is never rendered. The RBR still shows on the expense preview because it is driven by the raw violation, not by this status-bar branch — which matches the reported symptom ("RBR only shown on expense preview").

So: violation without cardID → card is undefined → isPersonalCard(undefined) defaults to true → header treats it as a broken personal card and returns undefined → admin message violations.adminBrokenConnectionError (the one BrokenConnectionDescription would have produced for an admin who is not the submitter) is never shown.

BrokenConnectionDescription itself is correct — for an admin viewing someone else's expense it returns the expected admin copy, so the issue is purely that the header never reaches it:

App/src/components/BrokenConnectionDescription.tsx

Lines 42 to 43 in d81cc58

	if (isPolicyAdmin && !isCurrentUserSubmitter(report)) {
	return <RenderHTML html={translate('violations.adminBrokenConnectionError', {workspaceCompanyCardRoute})} />;

The gating helper also correctly returns true for this case (admin + processing report + instant submit), so it is not the cause:

App/src/libs/TransactionUtils/index.ts

Lines 1594 to 1608 in d81cc58

	function shouldShowBrokenConnectionViolationInternal(brokenConnectionViolations: TransactionViolation[], report: OnyxEntry<Report>, policy: OnyxEntry<Policy>) {
	if (brokenConnectionViolations.length === 0) {
	return false;
	}
	if (!isPolicyAdmin(policy) || isCurrentUserSubmitter(report)) {
	return true;
	}
	if (isOpenExpenseReport(report)) {
	return true;
	}
	return isProcessingReport(report) && isInstantSubmitEnabled(policy);
	}

The exact same bug exists in the sibling report-level status bar used by MoneyReportHeaderStatusBarSection, so the report header is affected the same way:

App/src/hooks/useMoneyReportHeaderStatusBar.ts

Lines 111 to 119 in d81cc58

	if (!!transaction?.transactionID && !!transactionViolations.length && shouldShowBrokenConnectionViolation) {
	const brokenConnectionError = transactionViolations.find((violation) => violation.data?.rterType === CONST.RTER_VIOLATION_TYPES.BROKEN_CARD_CONNECTION);
	const cardID = brokenConnectionError?.data?.cardID;
	const card = cardID ? cardList?.[cardID] : undefined;
	if (isPersonalCard(card) && brokenConnectionError) {
	return undefined;
	}
	return CONST.REPORT.STATUS_BAR_TYPE.BROKEN_CONNECTION;
	}

const card = cardID ? cardList?.[cardID] : undefined;
if (isPersonalCard(card) && brokenConnectionError) {
    return undefined;
}

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

The personal-card suppression must only apply when a card was actually resolved. Guard the isPersonalCard call with the resolved card so an unresolvable/missing cardID no longer falls through to the personal-card default.

In MoneyRequestHeader (L126-L128):

const isBrokenPersonalCard = !!card && isPersonalCard(card);

Apply the identical guard in the sibling useMoneyReportHeaderStatusBar (L115):

if (!!card && isPersonalCard(card) && brokenConnectionError) {

isPersonalCard is already imported and in scope in both files (header import, hook import), so this is a minimal, behavior-preserving change: genuinely broken personal cards (where card resolves and is personal) still short-circuit to their dedicated receipt-audit message, while company-card / cardID-less broken connections now correctly render the BROKEN_CONNECTION status. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Reuse the existing isPersonalCardBrokenConnection helper (CardUtils L1469-L1471) instead of isPersonalCard. It returns falsy for an undefined card (it requires card?.lastScrapeResult) and is semantically the "is this a broken personal-card connection" check, which reads more intentionally here. The !!card && isPersonalCard(card) guard is the smaller, lower-risk change since it preserves the current truthiness semantics for resolved cards; switching helpers also changes behavior for resolved personal cards whose lastScrapeResult is in BROKEN_CONNECTION_IGNORED_STATUSES, so it should only be done if that is the intended behavior.

[MobileMage]

Proposal

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

When an admin opens an expense (submitted by a member) on a workspace with Instant submit enabled, and the transaction carries an rter violation with data.rterType === 'brokenCardConnection' but no cardID, the "Receipt pending due to broken bank connection. Please resolve in Company cards." status message is not rendered on the expense detail view. Only the RBR dot shows on the expense preview. The message should appear in the status bar of the transaction detail view.

What is the root cause of that problem?

The status message comes from BrokenConnectionDescription, which is rendered as the status-bar description in MoneyRequestHeader (transaction detail header) and in MoneyReportHeaderStatusBarSection (report header). Before that component is ever reached, MoneyRequestHeader.getStatusBarProps() runs a personal-card gate that short-circuits and returns undefined, suppressing the whole status bar:

App/src/components/MoneyRequestHeader.tsx

Lines 122 to 126 in 5b46d9a

	if (!!transaction?.transactionID && !!transactionViolations.length && shouldShowBrokenConnectionViolation) {
	const brokenConnectionError = transactionViolations?.find((violation) => violation.data?.rterType === CONST.RTER_VIOLATION_TYPES.BROKEN_CARD_CONNECTION);
	const cardID = brokenConnectionError?.data?.cardID;
	const card = cardID ? cardList?.[cardID] : undefined;
	const isBrokenPersonalCard = isPersonalCard(card);

The intent of that gate (added in PR #93066) is to hide the company-card message when the violation actually belongs to a personal card, since personal cards get their own broken-connection link in MoneyRequestView. But the implementation determines "personal card" by passing the resolved card object into isPersonalCard:

App/src/libs/CardUtils.ts

Lines 1536 to 1538 in 5b46d9a

	function isPersonalCard(card?: Card) {
	return !card?.fundID || card.fundID === '0' || card?.bank === CONST.PERSONAL_CARDS.BANK_NAME.CSV;
	}

isPersonalCard returns true for a falsy card because of the leading !card?.fundID short-circuit. In this repro the optimistic violation has no cardID, so const card = cardID ? cardList?.[cardID] : undefined resolves to undefined, isPersonalCard(undefined) returns true, isBrokenPersonalCard && brokenConnectionError is true, and the function returns undefined — no status bar. The cardID field's own type doc says it is "used to determine if it's a personal or company card," so a violation without a cardID (or whose card isn't in cardList) must NOT be classified as personal. The exact same broken gate exists in the report-header path inside useMoneyReportHeaderStatusBar, where it returns undefined for statusBarType (which makes MoneyReportHeaderStatusBarSection render null):

App/src/hooks/useMoneyReportHeaderStatusBar.ts

Lines 113 to 117 in 5b46d9a

	const cardID = brokenConnectionError?.data?.cardID;
	const card = cardID ? cardList?.[cardID] : undefined;
	if (isPersonalCard(card) && brokenConnectionError) {
	return undefined;
	}

So shouldShowBrokenConnectionViolation correctly evaluates to true (admin, not submitter, processing report, instant submit on), but both consumers then incorrectly drop the message because an absent card is misread as a personal card.

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

Only treat the violation as a personal-card connection when a card was actually resolved. The personal-card suppression should require card to exist, so a missing/unknown card falls through to the company-card message. In MoneyRequestHeader.tsx change the gate to:

const card = cardID ? cardList?.[cardID] : undefined;
const isBrokenPersonalCard = !!card && isPersonalCard(card);

if (isBrokenPersonalCard && brokenConnectionError) {
    return undefined;
}

Apply the identical !!card && guard to the matching block in useMoneyReportHeaderStatusBar.ts (lines 113-117). This is safe: a genuine personal-card broken connection still has a cardID that resolves to a personal card in cardList, so it keeps being suppressed exactly as before; the only changed behavior is that a broken-card-connection violation whose card is absent now shows the company-card message, which is the correct default for a company-card RTER and matches pre-#93066 behavior. It does not touch isPersonalCard's other callers (they pass real cards) and does not affect shouldShowBrokenConnectionViolation.

What alternative solutions did you explore? (Optional)

Tightening isPersonalCard itself to return false for a falsy card would centralize the fix, but it is broadly consumed (e.g. card-feed filtering and workspace card lists) where flipping the undefined-card result could change unrelated behavior, so a local guard at the two status-bar call sites is the lower-risk, targeted change.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-19 10:55:17 UTC.

Proposal

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

When an admin views a member's expense that has a brokenCardConnection (rter) violation, the red dot shows on the expense preview but the header status-bar message "Receipt pending due to broken bank connection. Please resolve in Company cards." is never shown.

What is the root cause of that problem?

The preview and the header decide to surface the broken connection using different conditions.

1. The preview RBR/violation text is driven purely by the presence of the violation — no report-state gate: firstViolation → getViolationTranslation. That is why the red dot shows.
2. The header message is rendered by BrokenConnectionDescription (adminBrokenConnectionError), but it only mounts when shouldShowBrokenConnectionViolation is true.
3. That gate's admin-non-submitter branch is the structural cause: return isProcessingReport(report) && isInstantSubmitEnabled(policy). For an admin viewing the member's report this compound condition is false (the report is not in the exact SUBMITTED/SUBMITTED + instant-submit combo), so the message is suppressed even though the violation — and the RBR — are present.

The same gate backs the report-level status bar (useMoneyReportHeaderStatusBar), so both header surfaces are affected; only the ungated preview escapes it.

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

In shouldShowBrokenConnectionViolationInternal, decouple the admin message from the instant-submit/processing combo so it tracks the same signal as the RBR — the violation being present on an actionable (non-settled) report:

if (isOpenExpenseReport(report) || isProcessingReport(report) || isReportApproved({report})) {
    return true;
}
return false;

This fixes both the expense header and the report status bar from one chokepoint. Regression safety: members/submitters still hit the earlier return true, and settled/paid reports still return false, so no message appears where the connection is no longer actionable.

What alternative solutions did you explore? (Optional)

• Keep && isInstantSubmitEnabled(policy) and only relax isProcessingReport — incomplete: it still hides the message on approved/closed-but-unsettled reports the admin must fix.
• Fix it in BrokenConnectionDescription — wrong layer: it already renders the correct message; it is simply never mounted because the upstream gate returns false.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 15:57:49 UTC.

Proposal

What is the root cause of that problem?

The broken-connection status bar is suppressed by a personal-card check that reads the card from a viewer-scoped card list.

In MoneyRequestHeader.tsx#L122-L141 the card is resolved as card = cardID ? cardList?.[cardID] : undefined, where cardList is ONYXKEYS.CARD_LIST — documented as "The user's cash card and imported cards", i.e. the current viewer's own cards. An admin viewing a member's expense can never resolve the member's card from their own list, so card is undefined regardless of whether the violation carries a cardID.

isPersonalCard(undefined) then returns true (its first check !card?.fundID evaluates to !undefined → true), so isBrokenPersonalCard && brokenConnectionError is satisfied and getStatusBarProps returns undefined — the status bar is never built.

Two clarifications that rule out the other candidate causes:

• The upstream gate shouldShowBrokenConnectionViolationInternal correctly returns true here (admin, non-submitter, processing report, instant submit enabled), so the gate is not the cause — execution reaches the personal-card check and is suppressed there.
• BrokenConnectionDescription already has a dedicated isPolicyAdmin && !isCurrentUserSubmitter branch that produces the exact expected admin copy — it is simply never mounted because the suppression above short-circuits first.

The identical suppression exists in the report-header path at useMoneyReportHeaderStatusBar.ts#L111-L119, so both header surfaces are affected. The RBR still shows on the preview because it is driven only by the violation's presence, not by this suppressed status-bar branch.

This is why it is a real app bug, not a repro-setup gap: assigning a card to the submitter still won't put that card into the admin's CARD_LIST, so the message stays suppressed for every admin / non-owner viewer.

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

Only treat the violation as a personal-card connection when a card was actually resolved, so an unresolved card (any non-owner viewer, or a missing cardID) falls through to the company-card message instead of being misclassified as personal.

At the MoneyRequestHeader call site, compute the personal-card flag as roughly:

isBrokenPersonalCard = !!card && isPersonalCard(card)

and apply the identical guard to the matching block in useMoneyReportHeaderStatusBar. This preserves the original intent — a genuine personal-card broken connection (where card resolves for its owner and is personal) stays suppressed because it surfaces its own link in MoneyRequestView — while company-card / non-owner cases correctly render BrokenConnectionDescription's admin copy. It touches no other isPersonalCard callers and does not change shouldShowBrokenConnectionViolation, so there is no regression risk.

What alternative solutions did you explore? (Optional)

Key the suppression off the authoritative, intent-named source useCardFeedErrors().personalCardsWithBrokenConnection (suppress only when cardID is positively a known personal broken card). This makes the classification correct rather than incidentally falsy; it yields the same behavior as the !!card && guard but is more explicit. Hardening isPersonalCard itself to return false for a missing card was rejected — it is broadly consumed and could change unrelated card-classification behavior elsewhere.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).