[$250] Android - Workspace - Brief Error Blink Before Opening Company Cards

[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: v9.4.25-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94342
Email or phone of affected tester (no customers): sintayewhaylu01@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung A16/ Android 15
App Component: Workspace Settings

Action Performed:

1. Open the hybrid app.
2. Create a new workspace.
3. Open the Company Cards feature.
4. Repeat steps 2–3 multiple times.

Expected Result:

A loading spinner should appear while the Company Cards page is loading, and the page should open without showing any error.

Actual Result:

A brief error message/screen flashes (blinks) before the Company Cards page opens. The error disappears immediately, and the page loads afterward.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7195421_1782826775882.video_2026-06-30_16-36-36.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7195421

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071961080925474003
• Upwork Job ID: 2071961080925474003
• Last Price Increase: 2026-07-28

Issue Owner

Current Issue Owner: @lorretheboy

[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/2b13167529e2c5658edbd8bbbfff047febb3c92c4499f8798e6cf73c06372d31

[MobileMage]

Proposal

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

When a brand-new workspace opens the Company Cards page on Android (and any platform), the "Workspace feeds could not be loaded" error screen (the BrokenMagnifyingGlass BlockingView) flashes for a frame before the loading spinner and the page content render. The error then disappears on its own once the company-cards data arrives. This is a regression from PR #94342.

What is the root cause of that problem?

For a freshly created workspace the policy's policyAccountID is not populated yet, so workspaceAccountID = policy?.policyAccountID ?? CONST.DEFAULT_NUMBER_ID resolves to 0, and with no feed selected getDomainOrWorkspaceAccountID (which just returns cardFeedData?.domainID ?? workspaceAccountID) also returns 0. In WorkspaceCompanyCardsTable, that makes shouldShowWorkspaceFeedsLoadError true as soon as the policy is loaded, so a synthetic WORKSPACE_FEEDS_LOAD_ERROR is fabricated and feedErrorKey becomes truthy:

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Lines 107 to 117 in fb967fe

	// Synthesize error locally since Onyx discards writes to collection keys with member ID '0'.
	const shouldShowWorkspaceFeedsLoadError = domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && isPolicyLoaded && !isOffline;
	const workspaceCardFeedsErrors = shouldShowWorkspaceFeedsLoadError
	? {[CONST.COMPANY_CARDS.WORKSPACE_FEEDS_LOAD_ERROR]: translate('workspace.companyCards.error.workspaceFeedsCouldNotBeLoadedMessage')}
	: workspaceCardFeedsStatus?.[domainOrWorkspaceAccountID]?.errors;
	const selectedFeedStatus = selectedFeed?.status;
	const selectedFeedErrors = selectedFeedStatus?.errors;
	const [feedErrorKey, feedErrorMessage] = Object.entries(workspaceCardFeedsErrors ?? selectedFeedErrors ?? {}).at(0) ?? [];
	const hasFeedErrors = !!feedErrorKey;

The error view is gated only by !!feedErrorKey && !isLoading. The blink happens because, for an account ID of 0, nothing keeps isLoading true while the OpenPolicyCompanyCardsPage API request is in flight. isLoading = isLoadingPage || isLoadingFeed, and the only signals that hold it true for a new workspace are local Onyx reads, isInitiallyLoadingFeeds (the allCardFeeds metadata) and personalDetailsMetadata, both of which resolve almost instantly. Crucially, areWorkspaceCardFeedsLoading (workspaceCardFeedsStatus?.[domainOrWorkspaceAccountID]?.isLoading) is never set for account 0, because openPolicyCompanyCardsPage deliberately skips its optimistic isLoading: true write when the account ID is the default: const onyxLoadingStateUpdates = domainOrWorkspaceAccountID !== CONST.DEFAULT_NUMBER_ID; (Onyx discards writes to collection keys ending in member ID 0). So once the fast local reads settle, isLoading flips to false while the network read is still pending and feedErrorKey is still the synthesized error, and the error BlockingView renders for that window:

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Lines 416 to 436 in fb967fe

	{!!feedErrorKey && !isLoading && (
	<ScrollView contentContainerStyle={[styles.flex1, styles.alignItemsCenter, styles.justifyContentCenter, bottomSafeAreaPaddingStyle]}>
	<View style={[styles.alignItemsCenter]}>
	<BlockingView
	icon={illustrations.BrokenMagnifyingGlass}
	iconWidth={variables.companyCardsPageNotFoundIconWidth}
	iconHeight={variables.companyCardsPageNotFoundIconHeight}
	title={feedErrorTitle ?? ''}
	subtitle={feedErrorMessage ?? undefined}
	containerStyle={[styles.companyCardsBlockingErrorViewContainer, styles.pb4]}
	titleStyles={[styles.mb2, styles.mt8]}
	subtitleStyle={styles.textSupporting}
	/>
	<Button
	text={translate('workspace.companyCards.error.tryAgain')}
	isDisabled={isOffline}
	onPress={feedErrorReloadAction}
	/>
	</View>
	</ScrollView>
	)}

This race existed in logic before, but PR #94342 (jsenyitko-loading-indicators) made it visible. The previous version rendered a full opaque TableSkeleton (5 rows plus header that fill the viewport) as the loading state; #94342 replaced it with a single small centered ActivityIndicator. With the heavy skeleton gone, the brief error frame is no longer visually covered and now reads as a distinct error blink. The error-render condition itself (!!feedErrorKey && !isLoading) is byte-identical before and after the PR. The regression is that the loading state no longer masks the synthesized-error frame for new workspaces whose domainOrWorkspaceAccountID is 0.

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

The synthesized WORKSPACE_FEEDS_LOAD_ERROR should only be treated as a real error once the workspace has actually been provisioned. While a brand-new workspace is still being created, its policyAccountID is not assigned yet, so domainOrWorkspaceAccountID resolves to 0 for a reason that is not a failure. The signal that distinguishes "still provisioning" from "genuinely invalid account" is the optimistic policy's pendingAction: createWorkspace / buildPolicyData set pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD on the optimistic policy (with policyAccountID undefined), and the CreateWorkspace success data clears pendingAction to null in the same Onyx batch that the server's real policyAccountID arrives in.

So gate "policy loaded" on the workspace no longer being mid-creation, in WorkspaceCompanyCardsPage:

isPolicyLoaded={!!policy && policy.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD}

This routes through the table's existing logic and needs no other change. While the workspace is provisioning, isPolicyLoaded is false, so isLoadingFeed (which already includes || !isPolicyLoaded) stays true, isLoading stays true, and the loading spinner is shown for the whole window while the synthesized error stays suppressed (the error branch requires isPolicyLoaded). When CreateWorkspace returns, pendingAction clears and policyAccountID populates in the same render, so the page goes straight from the spinner to the empty state with no intermediate error frame.

This keeps the genuine error path intact. A workspace whose account is persistently 0 (an existing policy whose pendingAction is already cleared but that still has no valid account ID, which is the case the synthesized error was originally added for) still has isPolicyLoaded === true, so the error still shows. Only the transient provisioning window is masked.

One trade-off: creating a workspace while offline would show the spinner until reconnect instead of the empty state. That is an acceptable edge because a brand-new workspace cannot be provisioned offline anyway, but if preserving the offline empty state matters, the alternative is to leave isPolicyLoaded unchanged and instead add the pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD guard directly to shouldShowWorkspaceFeedsLoadError, plumbing the provisioning flag down from the page.

What alternative solutions did you explore? (Optional)

Holding isLoading true via the feeds signal (for example domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && !hasCards && isInitiallyLoadingFeeds) does not actually close the gap. By the time the error frame renders, isLoadingFeed has already become false, which means isInitiallyLoadingFeeds is already false at that same frame, so that term cannot keep isLoading true during the window that matters. The provisioning pendingAction signal is the only one that is still distinguishing at the error frame.

Restoring the old full TableSkeleton as the loading component would re-mask the frame, but that reverts PR #94342's intended UX and only hides the symptom instead of fixing the loading and error race.

[aswin-s]

Proposal

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

On Android (hybrid app), when a user creates a new workspace and immediately opens its Company Cards page, a brief error screen ("workspace feeds could not be loaded") blinks before the loading spinner / cards page appears. Expected: only the loading spinner should show until the page is ready, with no error flash in between.

What is the root cause of that problem?

In src/components/Tables/WorkspaceCompanyCardsTable/index.tsx:108, the synthesized "workspace feeds load error" is gated only on domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && isPolicyLoaded && !isOffline. For a freshly created workspace, policy.policyAccountID is 0 (DEFAULT_NUMBER_ID) until the create-workspace API response replaces it, but policy itself is in Onyx almost immediately, so isPolicyLoaded flips to true before the company-cards fetch has started/completed. That makes shouldShowWorkspaceFeedsLoadError (line 108) true for one render, hasFeedErrors becomes true (line 117), so the feedErrorKey branch (line 416) renders the BlockingView error before openPolicyCompanyCardsPage (WorkspaceCompanyCardsPage.tsx:75) resolves and policyAccountID is replaced — at which point the error disappears and the spinner/cards render.

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

1. src/components/Tables/WorkspaceCompanyCardsTable/index.tsx:108 — additionally require that the page is NOT in a loading state before synthesizing the workspace-feeds-load error, e.g. ... && isPolicyLoaded && !isOffline && !isLoadingPage && !areWorkspaceCardFeedsLoading so the error is only shown after the fetch has actually had a chance to run.
2. Equivalently, gate the synthesized error on policy?.pendingAction !== ADD (or on policy?.policyAccountID having been populated to a non-default value through a real server response) so newly-created workspaces don't trip the DEFAULT_NUMBER_ID heuristic while the workspace creation is still in flight.
3. Reorder the conditional render so the loading branch (line 391) takes precedence over the feedErrorKey branch (line 416) — i.e. while isLoading is true, suppress the BlockingView even if hasFeedErrors is momentarily true. This guarantees no error flash during initial mount on any platform.
4. Verify the same pattern in WorkspaceCompanyCardsPage.tsx's isLoading computation (line 66) so it stays true until workspaceAccountID is a real (non-default) ID for freshly-created workspaces.

What alternative solutions did you explore? (Optional)

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 14:23:53 UTC.

Proposal

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

When you create a new workspace and open its Company Cards page, an error screen ("Workspace feeds could not be loaded") flashes for a frame before the page settles into its normal empty/cards state. The error then clears on its own. It was caught on Android but the underlying cause is timing-dependent, so it can show on any platform.

What is the root cause of that problem?

A freshly created workspace has no policyAccountID yet (the optimistic policy is written without one and the server fills it in later), so on WorkspaceCompanyCardsPage.tsx:35 the account ID falls back to 0:

const workspaceAccountID = policy?.policyAccountID ?? CONST.DEFAULT_NUMBER_ID;

With no feed selected, getDomainOrWorkspaceAccountID returns that same 0, and the table synthesizes a fake load error from the ID alone at WorkspaceCompanyCardsTable/index.tsx:108:

const shouldShowWorkspaceFeedsLoadError = domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && isPolicyLoaded && !isOffline;

That synthetic error is meant for a real failure case (workspace created while network requests were failing — added in commit 38bfa2f221e, fixes #81115). The problem is it can't tell "account is 0 because the fetch failed" apart from "account is 0 because the fetch hasn't finished yet."

What normally hides the error during that window is isLoading, since the error only renders on index.tsx:416 via {!!feedErrorKey && !isLoading}. But for account 0 there's no network signal holding isLoading true. The one signal that would, areWorkspaceCardFeedsLoading (workspaceCardFeedsStatus[0].isLoading), is never written: openPolicyCompanyCardsPage (CompanyCards.ts:921-936) deliberately skips the optimistic loading write when the account ID is 0, because Onyx discards writes to collection keys ending in member ID 0. So isLoading rides only fast local Onyx reads (feed metadata, personal-details metadata), which settle almost instantly. It flips to false while the network read is still pending and the synthesized error is still set, and the BrokenMagnifyingGlass BlockingView renders for that frame. A moment later policyAccountID arrives, the account ID becomes real, the error clears, and the page renders.

The race itself predates PR #94342. That PR swapped the full-viewport TableSkeleton for a small ActivityIndicator, and the error gate (!!feedErrorKey && !isLoading) is byte-identical before and after. The heavy skeleton used to cover the screen during that frame, so the error was there but invisible. With just a small spinner now, the error frame shows through. That's why it's reproducible on staging but not production.

I'll also flag a secondary issue right next to this. On index.tsx:116, workspaceCardFeedsErrors ?? selectedFeedErrors uses ??, but workspaceCardFeedsErrors can be an empty {} object, which is truthy and won't fall through to selectedFeedErrors. That can swallow a genuine selected-feed error. And the synthetic-error "Try again" button calls openPolicyCompanyCardsPage(…, 0, …), which writes no optimistic loading state, so retrying gives the user no visible feedback.

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

Don't fold account-0 into isLoading unconditionally. If you do that, the real #81115 failure case (account stays 0 because the request actually failed) would spin forever instead of showing its error. The fix is to gate the synthetic error on the page fetch having completed at least once, so a still-pending fetch reads as loading and a finished-but-failed fetch reads as error:

shouldShowWorkspaceFeedsLoadError = domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && isPolicyLoaded && !isOffline && hasCompletedInitialPageFetch

Since openPolicyCompanyCardsPage can't track loading on the 0 key, derive hasCompletedInitialPageFetch in the page from the page-fetch lifecycle and pass it into the table. This keeps the genuine member-ID-0 error working (it still shows after the fetch settles) while removing the flash on initial load. While we're in this file, I'd switch the index.tsx:116 ?? chain so an empty errors object falls through to the selected-feed error instead of masking it.

There's no test covering this gate today (getShouldShowBrokenConnectionErrorTest.ts is the only related test), so I'd add cases: account-0 with the fetch still in flight asserts the spinner and no error, and account-0 after a failed fetch asserts the error still renders.

What alternative solutions did you explore? (Optional)

Reordering the loading and error render branches doesn't help. They're mutually exclusive on isLoading, and isLoading is already false in the bad window, so the error still wins. Routing loading/error off the member-0 key entirely (and deleting the === 0 heuristic) would be the cleanest in theory but it's far more invasive and would have to fight the documented Onyx member-0 limitation, so I'd keep the fix local to the page and table.

[lorretheboy]

Proposal

What is the root cause of that problem?

When a workspace is freshly created, policy.policyAccountID hasn't been returned by the backend yet, so workspaceAccountID (and therefore domainOrWorkspaceAccountID) briefly falls back to CONST.DEFAULT_NUMBER_ID (0):

App/src/pages/workspace/companyCards/WorkspaceCompanyCardsPage.tsx

Line 35 in fb967fe

const workspaceAccountID = policy?.policyAccountID ?? CONST.DEFAULT_NUMBER_ID;

The table synthesizes a "feeds couldn't be loaded" error purely from that 0 value:

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Line 108 in fb967fe

const shouldShowWorkspaceFeedsLoadError = domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && isPolicyLoaded && !isOffline;

That flag is meant for the permanent member‑ID‑0 case (Onyx discards those collection writes), but it also fires during the transient window where a new workspace's account ID simply hasn't resolved. It feeds feedErrorKey/hasFeedErrors, and the error BlockingView renders the instant isLoading is momentarily false:

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Line 416 in fb967fe

{!!feedErrorKey && !isLoading && (

Causal chain: new workspace → policyAccountID not yet returned → domainOrWorkspaceAccountID === 0 → shouldShowWorkspaceFeedsLoadError true → feedErrorKey set → once metadata finishes and isLoading flips false before the account ID resolves, the error flashes → account ID arrives → error clears → empty state/cards render.

Note: PR #94342 only restructured the loading/empty JSX and swapped the skeleton for a spinner in this file; the synthesized‑error condition and its !isLoading gate are unchanged, so this race pre‑dates the PR and was merely surfaced during its QA.

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

Don't treat the transient unresolved account ID as a load error. A new workspace whose policyAccountID is still 0 (and whose feeds fetch hasn't completed) is loading, not failed, so the spinner should stay up until either the real account ID resolves or the fetch genuinely finishes with nothing.

Concretely, gate shouldShowWorkspaceFeedsLoadError (here) so it only synthesizes the error once the company‑cards page fetch has completed, rather than firing off domainOrWorkspaceAccountID === DEFAULT_NUMBER_ID alone:

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Line 108 in fb967fe

const shouldShowWorkspaceFeedsLoadError = domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && isPolicyLoaded && !isOffline;

Equivalently, fold the "new workspace account ID not yet resolved" case into the loading state so isLoading stays true across that window:

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Lines 133 to 138 in fb967fe

	const isLoadingFeed =
	!hasCards && ((!feedName && isInitiallyLoadingFeeds) || !isPolicyLoaded || (!isNoFeed && isLoadingOnyxValue(lastSelectedFeedMetadata)) || !!selectedFeedStatus?.isLoading);
	const isLoadingCards = !hasCards && isLoadingOnyxValue(cardListMetadata);
	const isLoadingPage = !isOffline && !hasCards && (isLoadingFeed || isLoadingOnyxValue(personalDetailsMetadata) || areWorkspaceCardFeedsLoading);
	const isLoading = isLoadingPage || isLoadingFeed;

This keeps the genuine permanent member‑ID‑0 error working (it still shows after the fetch settles) while removing the flash on initial load.

What alternative solutions did you explore? (Optional)

Make isPolicyLoaded reflect a fully‑loaded policy (i.e. policyAccountID resolved) instead of just !!policy, so the table never sees the 0 account ID with isPolicyLoaded === true during the settle window.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

For a newly-created workspace, the optimistic policy enables Company Cards before policyAccountID is hydrated from the server (areCompanyCardsEnabled is set in the optimistic policy, but there is no policyAccountID in that optimistic value: https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/Policy.ts#L2664-L2692). WorkspaceCompanyCardsPage then falls back to CONST.DEFAULT_NUMBER_ID for the workspace account ID and passes that through getDomainOrWorkspaceAccountID while no selected feed exists yet (https://github.com/Expensify/App/blob/main/src/pages/workspace/companyCards/WorkspaceCompanyCardsPage.tsx#L33-L49, https://github.com/Expensify/App/blob/main/src/libs/CardUtils.ts#L874-L876). The page load action already knows 0 is not a real collection member and skips optimistic loading/error writes for that key (https://github.com/Expensify/App/blob/main/src/libs/actions/CompanyCards.ts#L921-L936), but WorkspaceCompanyCardsTable treats domainOrWorkspaceAccountID === 0 plus a loaded policy as a synthetic WORKSPACE_FEEDS_LOAD_ERROR (https://github.com/Expensify/App/blob/main/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx#L104-L117). That makes the table briefly render the “Couldn’t load card feeds” blocking view before the real workspace account/feed data arrives and the normal Company Cards page replaces it (https://github.com/Expensify/App/blob/main/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx#L416-L436).

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

Stop treating the temporary default workspace account ID as an immediate load failure. Instead, add an explicit “workspace account ID is still pending” loading state for the Company Cards page when we are online, the policy is loaded, there is no selected feed/domain feed, and workspaceAccountID === CONST.DEFAULT_NUMBER_ID. Pass that state from WorkspaceCompanyCardsPage into WorkspaceCompanyCardsTable and include it in the table’s loading calculation so the spinner is shown while the new workspace finishes hydrating.

Then gate or remove the local shouldShowWorkspaceFeedsLoadError branch so WORKSPACE_FEEDS_LOAD_ERROR is only shown from an actual failed load signal, not from domainOrWorkspaceAccountID === 0 by itself. The existing openPolicyCompanyCardsPage behavior can keep skipping Onyx writes for key 0; the UI just should not infer an error from that skipped write. Once policyAccountID or a linked domain feed is available, the existing openPolicyCompanyCardsPage / openPolicyCompanyCardsFeed flow can continue using the real ID and the table can render the empty BYOC state, feed-pending state, cards table, or real feed error as it does today.

What alternative solutions did you explore? (Optional)

I also considered changing openPolicyCompanyCardsPage to write loading/error state under the 0 collection key, but that would fight the existing Onyx limitation documented in the action. Handling the missing workspace account ID as a temporary loading state in the page/table keeps the fix local and avoids introducing a fake collection member.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 14:30:44 UTC.

Proposal

What is the root cause of that problem?

For a newly created workspace, the Company Cards page can reach the table before the workspace account/domain ID has been resolved. The page derives domainOrWorkspaceAccountID from the selected feed or the policy policyAccountID, then starts OpenPolicyCompanyCardsPage when no company-card feeds are loaded.

App/src/pages/workspace/companyCards/WorkspaceCompanyCardsPage.tsx

Lines 35 to 48 in fb967fe

	const workspaceAccountID = policy?.policyAccountID ?? CONST.DEFAULT_NUMBER_ID;
	const companyCards = useCompanyCards({policyID});
	const {
	allCardFeeds,
	feedName,
	selectedFeed,
	bankName,
	isFeedPending,
	isFeedAdded,
	onyxMetadata: {cardListMetadata},
	} = companyCards;
	const domainOrWorkspaceAccountID = getDomainOrWorkspaceAccountID(workspaceAccountID, selectedFeed);

App/src/pages/workspace/companyCards/WorkspaceCompanyCardsPage.tsx

Lines 66 to 76 in fb967fe

	const isLoading = !isOffline && (!allCardFeeds || (isFeedAdded && isLoadingOnyxValue(cardListMetadata)));
	const hasFeedsLoaded = !!allCardFeeds && Object.keys(allCardFeeds).length > 0;
	useEffect(() => {
	if (isOffline || hasFeedsLoaded) {
	return;
	}
	loadPolicyCompanyCardsPage();
	}, [loadPolicyCompanyCardsPage, isOffline, hasFeedsLoaded]);

When that derived ID is 0, openPolicyCompanyCardsPage() intentionally skips the normal optimistic/success/failure Onyx loading updates because Onyx discards writes to sharedNVP_private_domain_member_0.

App/src/libs/actions/CompanyCards.ts

Lines 921 to 970 in fb967fe

	function openPolicyCompanyCardsPage(policyID: string, domainOrWorkspaceAccountID: number, emailList: string[], translate: LocaleContextProps['translate']) {
	// Skip loading state writes when domainOrWorkspaceAccountID is 0 since Onyx discards writes to collection keys with member ID '0'.
	const onyxLoadingStateUpdates = domainOrWorkspaceAccountID !== CONST.DEFAULT_NUMBER_ID;
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER>> = onyxLoadingStateUpdates
	? [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER}${domainOrWorkspaceAccountID}`,
	value: {
	isLoading: true,
	errors: null,
	},
	},
	]
	: [];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER>> = onyxLoadingStateUpdates
	? [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER}${domainOrWorkspaceAccountID}`,
	value: {
	isLoading: false,
	},
	},
	]
	: [];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER>> = onyxLoadingStateUpdates
	? [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER}${domainOrWorkspaceAccountID}`,
	value: {
	isLoading: false,
	errors: {
	[CONST.COMPANY_CARDS.WORKSPACE_FEEDS_LOAD_ERROR]: translate('workspace.companyCards.error.workspaceFeedsCouldNotBeLoadedMessage'),
	},
	},
	},
	]
	: [];
	const params: OpenPolicyExpensifyCardsPageParams = {
	policyID,
	emailList: JSON.stringify(emailList),
	};
	API.read(READ_COMMANDS.OPEN_POLICY_COMPANY_CARDS_PAGE, params, {optimisticData, successData, failureData});

The table then treats domainOrWorkspaceAccountID === 0 as an immediate workspace-feed load error whenever the policy is loaded and the app is online. That turns the normal in-flight zero-ID state into the "Couldn't load card feeds" blocking view before the request has settled, so the error flashes until the Company Cards data or a real account/domain ID arrives.

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Lines 104 to 117 in fb967fe

	const hasNoAssignedCard = Object.keys(assignedCards ?? {}).length === 0;
	const areWorkspaceCardFeedsLoading = !!workspaceCardFeedsStatus?.[domainOrWorkspaceAccountID]?.isLoading;
	// Synthesize error locally since Onyx discards writes to collection keys with member ID '0'.
	const shouldShowWorkspaceFeedsLoadError = domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID && isPolicyLoaded && !isOffline;
	const workspaceCardFeedsErrors = shouldShowWorkspaceFeedsLoadError
	? {[CONST.COMPANY_CARDS.WORKSPACE_FEEDS_LOAD_ERROR]: translate('workspace.companyCards.error.workspaceFeedsCouldNotBeLoadedMessage')}
	: workspaceCardFeedsStatus?.[domainOrWorkspaceAccountID]?.errors;
	const selectedFeedStatus = selectedFeed?.status;
	const selectedFeedErrors = selectedFeedStatus?.errors;
	const [feedErrorKey, feedErrorMessage] = Object.entries(workspaceCardFeedsErrors ?? selectedFeedErrors ?? {}).at(0) ?? [];
	const hasFeedErrors = !!feedErrorKey;

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Lines 130 to 142 in fb967fe

	// If we already have fetched cards, then do not show a loading spinner (let the remaining updates refresh in the background), else show it
	const hasCards = (companyCardEntries ?? []).length > 0;
	// When the last feed is removed, card data already implies no feed (isNoFeed); lastSelectedFeed Onyx metadata can still report loading after optimistic clear.
	const isLoadingFeed =
	!hasCards && ((!feedName && isInitiallyLoadingFeeds) || !isPolicyLoaded || (!isNoFeed && isLoadingOnyxValue(lastSelectedFeedMetadata)) || !!selectedFeedStatus?.isLoading);
	const isLoadingCards = !hasCards && isLoadingOnyxValue(cardListMetadata);
	const isLoadingPage = !isOffline && !hasCards && (isLoadingFeed || isLoadingOnyxValue(personalDetailsMetadata) || areWorkspaceCardFeedsLoading);
	const isLoading = isLoadingPage || isLoadingFeed;
	const showCards = !isInitiallyLoadingFeeds && !isFeedPending && !isNoFeed && !isLoading && !hasFeedErrors;
	const showTableControls = showCards && !!selectedFeed && !isLoadingCards && !hasFeedErrors;
	const showTableHeaderButtons = (showTableControls || isLoadingPage || isFeedPending || feedErrorKey === CONST.COMPANY_CARDS.FEED_LOAD_ERROR) && !!feedName;

App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

Lines 416 to 435 in fb967fe

	{!!feedErrorKey && !isLoading && (
	<ScrollView contentContainerStyle={[styles.flex1, styles.alignItemsCenter, styles.justifyContentCenter, bottomSafeAreaPaddingStyle]}>
	<View style={[styles.alignItemsCenter]}>
	<BlockingView
	icon={illustrations.BrokenMagnifyingGlass}
	iconWidth={variables.companyCardsPageNotFoundIconWidth}
	iconHeight={variables.companyCardsPageNotFoundIconHeight}
	title={feedErrorTitle ?? ''}
	subtitle={feedErrorMessage ?? undefined}
	containerStyle={[styles.companyCardsBlockingErrorViewContainer, styles.pb4]}
	titleStyles={[styles.mb2, styles.mt8]}
	subtitleStyle={styles.textSupporting}
	/>
	<Button
	text={translate('workspace.companyCards.error.tryAgain')}
	isDisabled={isOffline}
	onPress={feedErrorReloadAction}
	/>
	</View>
	</ScrollView>

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

Do not synthesize the workspace-feed error from domainOrWorkspaceAccountID === 0 by itself. Add an explicit pending/failed state for the zero-ID OpenPolicyCompanyCardsPage request in an Onyx-safe request status key that is not sharedNVP_private_domain_member_0, or use an equivalent page-owned pending flag together with an explicit failure signal from that safe key.

Use that state in WorkspaceCompanyCardsTable: while the zero-ID page request is pending, render the existing loading spinner; only render the synthesized workspace-feed error after the request has explicitly failed; otherwise continue to the normal feed, no-feed, pending, and card-list states. This keeps the intended real-error fallback for the ID-0 path without showing it during normal loading.

Test coverage:

• Add a Company Cards page/table regression test for a loaded policy with domainOrWorkspaceAccountID === 0 while the page request is pending, and assert the loading spinner renders without the workspace-feed blocking error.
• Add a regression test for the explicit failed zero-ID request state, and assert the "Couldn't load card feeds" blocking error still renders.
• Manually verify on the Android hybrid app by creating multiple new workspaces, opening Company Cards each time, and confirming the spinner appears without the brief error blink before the page content loads.

What alternative solutions did you explore? (Optional)

I considered removing the synthetic domainOrWorkspaceAccountID === 0 error entirely, but that would hide real failures on the path where the normal collection-key error write is unavailable. Gating it behind an explicit failed request state keeps the real error behavior while preventing the transient false error.

[melvin-bot]

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