[$250] Offline - Agent avatar disappears from Share QR

[jponikarchuk]

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.34-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #95901
Email or phone of affected tester (no customers): testing210790@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11, Samsung a31
App Component: Other

Action Performed:

Preconditions
The account has an Agent created and enabled.
The Agent avatar has been selected and saved.
Clear app/browser cache before starting the test.

1. Log in with an account.
2. Go to Account > Profile.
3. Click the profile avatar.
4. Select any Agent avatar and tap Save.
5. Open the Share page and verify the agent avatar is displayed in the center of the QR code.
6. Go offline.
7. Reopen the Share page.

Expected Result:

The previously selected agent avatar remains visible in the center of the QR code while offline by using the local SVG fallback.

Actual Result:

After going offline, the agent avatar disappears from the center of the QR code, leaving the QR code without the selected agent avatar.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077078404999419655
• Upwork Job ID: 2077078404999419655
• Last Price Increase: 2026-07-14

[ijmalik]

Proposal

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

When the user's profile avatar is a catalog Agent avatar, the avatar shown in the center of the Share page QR code disappears while offline, instead of falling back to the bundled local SVG.

What is the root cause of that problem?

In src/pages/ShareCodePage.tsx (~line 125), the personal-QR logo is computed with getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, ...}), which for catalog-backed avatars deliberately resolves to the remote CloudFront PNG (findCatalogMatchForURL → catalog.getURL() in src/libs/UserAvatarUtils.ts). With the cache cleared and the device offline, that network image can't be fetched, so the QR logo renders empty. Everywhere else in the app agent avatars stay visible offline because they go through getAvatar() → findLocalAvatarForURL() (src/libs/Avatars/AvatarLookup.ts), which returns the bundled local SVG — ShareCodePage never uses that path.

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

In ShareCodePage.tsx, resolve the current user's avatar against the local catalog first, and when a local SVG exists pass it through the already-supported svgLogo prop of QRShareWithDownload (the same mechanism used for default workspace avatars) instead of the remote logo URL:

const localUserAvatar = !isReport ? findLocalAvatarForURL(currentUserPersonalDetails?.avatar) : undefined;

const logo = isReport
    ? getLogoForWorkspace(report, policy)
    : localUserAvatar
      ? undefined
      : (getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, accountID: currentUserPersonalDetails?.accountID}) as ImageSourcePropType);

let svgLogo: React.FC<SvgProps> | undefined = localUserAvatar;

Since findLocalAvatarForURL matches both AGENT_AVATARS and USER_AVATARS catalogs, this single change also fixes the identical offline failure for the pre-designed user avatars (default/Season catalog avatars), not just agent ones. Uploaded avatars keep the existing URL path, since they have no local asset. No fill color is needed because catalog SVGs are full-color assets.

What alternative solutions did you explore? (Optional)

Changing getAvatarURL itself to return local SVGs for catalog avatars was rejected — its contract is to return a URL string for sharing/external use, and other callers rely on that. Note that backend-generated letter avatars would still disappear offline (they are remote-only PNGs with no bundled asset); rendering those offline would require drawing initials into the QR logo and is out of scope for this bug.

[NicolasBonet]

@MelvinBot check how we can address this issue

[MelvinBot]

Proposal

What is the root cause of that problem?

The Share QR page feeds the agent avatar into the QR logo as a remote CDN URL string, not a bundled SVG — so it can't render without a network.

In ShareCodePage.tsx:125-127 the profile logo is always getAvatarURL(...), which for an agent avatar returns the CloudFront PNG URL (images/avatars/bot-avatar--*.png). That URL is passed to react-native-qrcode-svg's network-image logo prop, so offline the fetch fails and the center image goes blank.

The SVG-based path (svgLogo) that would render offline is gated by if (!logo && policy && !policy.avatarURL) at ShareCodePage.tsx:134 — on the profile page logo is always truthy and there's no policy, so svgLogo is never set for a user/agent avatar. PR #95901 fixed the CDN path from a 403 to the canonical URL, but the page still consumes a URL for agent avatars, which is inherently offline-fragile.

Evidence & data flow

• A bundled local SVG already exists for every agent avatar (DefaultBotAvatars.ts) and each catalog entry carries both local (SVG) and url (CDN PNG) — AgentAvatarCatalog.ts:12-23.
• getAvatarURL returns the CDN URL (getURL), whereas the sibling getAvatar returns the bundled SVG component (getLocal via findLocalAvatarForURL) for the same avatar.
• QRCode.tsx:90-99 passes logo (URL, network-fetched) and logoSVG={svgLogo} (bundled component, no network) as distinct props — only the latter survives offline.

Flow: select agent avatar → avatar becomes a bot-avatar--* CDN URL → getAvatarURL returns that URL → logo truthy, svgLogo undefined → QR fetches PNG over network → online works, offline blanks.

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

In ShareCodePage.tsx, resolve the profile avatar to its bundled local SVG when one exists, and route it through svgLogo instead of the URL logo:

• For the non-report branch, check findLocalAvatarForURL(currentUserPersonalDetails?.avatar).
• If it returns a component (agent avatars, and default avatars), assign it to svgLogo and leave logo undefined.
• Otherwise (uploaded user avatar → a real URL), keep the current getAvatarURL string in logo as today.

This reuses the already-bundled SVG assets, so the agent avatar renders offline with no new assets and no behavior change while online. A regression test asserting an agent avatar resolves to svgLogo (not logo) on the Share page should be added.

What alternative solutions did you explore? (Optional)

Use getAvatar(...) instead of getAvatarURL(...) for the profile branch — it returns the SVG component for catalog avatars and a URL string otherwise. It's the cleaner API but requires supplying the defaultAvatars (Concierge/Notifications) object it depends on, so the narrower findLocalAvatarForURL check above is lower-risk.

---

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

[abbasifaizan70]

@daledah @NicolasBonet Just for clarification, the proposal this was marked as a duplicate of was submitted before the Proposal Help wanted, external label was introduced. Since it predates that requirement, I don't think it should be used as the basis for marking this proposal as a duplicate.

Proposal

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

After a user selects an Agent (bot) avatar on Account > Profile and saves it, the avatar shows correctly in the center of the QR code on the Share page while online. Once the device goes offline and the Share page is reopened, the agent avatar disappears from the center of the QR code—it should instead keep showing the previously selected agent avatar by falling back to its local/bundled SVG.

What is the root cause of that problem?

ShareCodePage builds the QR-code center logo for a personal (non-report) share by calling getAvatarURL, and always treats the result as a remote image (ImageSourcePropType)—it never checks whether a local SVG equivalent exists for the selected avatar:

App/src/pages/ShareCodePage.tsx

Lines 125 to 127 in 9813012

	const logo = isReport
	? getLogoForWorkspace(report, policy)
	: (getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, accountID: currentUserPersonalDetails?.accountID}) as ImageSourcePropType);

getAvatarURL is explicitly documented and implemented to always return the CDN URL string for catalog-backed avatars (it calls match.catalog.getURL(match.id)), never the bundled local component:

App/src/libs/UserAvatarUtils.ts

Lines 365 to 374 in 9813012

	function getAvatarURL({accountID = CONST.DEFAULT_NUMBER_ID, avatarSource, accountEmail}: GetAvatarArgsType): AvatarSource | undefined {
	if (isDefaultAvatar(avatarSource)) {
	return getDefaultAvatarURL({accountID, accountEmail, avatarURL: avatarSource});
	}
	const match = findCatalogMatchForURL(avatarSource);
	if (match) {
	return match.catalog.getURL(match.id);
	}
	return avatarSource;
	}

Agent avatars are catalog-backed: each entry in AGENT_AVATAR_ENTRIES carries both a bundled local SVG component (e.g. BotAvatarBlue) and a CDN url used only for contexts that need a plain URL string (e.g. emails, non-JS contexts):

App/src/libs/Avatars/AgentAvatarCatalog.ts

Lines 14 to 21 in 9813012

	const AGENT_AVATAR_ENTRIES: Record<AgentAvatarID, AvatarEntry> = {
	'bot-avatar--blue': {local: BotAvatarBlue, url: `${CDN_BOT_AVATARS}/bot-avatar--blue.png`},
	'bot-avatar--green': {local: BotAvatarGreen, url: `${CDN_BOT_AVATARS}/bot-avatar--green.png`},
	'bot-avatar--ice': {local: BotAvatarIce, url: `${CDN_BOT_AVATARS}/bot-avatar--ice.png`},
	'bot-avatar--pink': {local: BotAvatarPink, url: `${CDN_BOT_AVATARS}/bot-avatar--pink.png`},
	'bot-avatar--tangerine': {local: BotAvatarTangerine, url: `${CDN_BOT_AVATARS}/bot-avatar--tangerine.png`},
	'bot-avatar--yellow': {local: BotAvatarYellow, url: `${CDN_BOT_AVATARS}/bot-avatar--yellow.png`},
	};

The codebase already has the mechanism to resolve a catalog avatar (User or Agent) back to its bundled local SVG—findLocalAvatarForURL—but ShareCodePage never calls it for the personal-avatar branch:

App/src/libs/Avatars/AvatarLookup.ts

Lines 1 to 27 in 9813012

	import type {SvgProps} from 'react-native-svg';
	import type {AvatarCatalog} from './AvatarCatalog';
	import {AGENT_AVATARS} from './AgentAvatarCatalog';
	import {USER_AVATARS} from './UserAvatarCatalog';
	// Catalogs whose entries are CDN-backed (not letter avatars), in lookup priority order.
	const CDN_CATALOGS: Array<AvatarCatalog<string>> = [USER_AVATARS, AGENT_AVATARS];
	function findCatalogMatchForURL(source: unknown): {catalog: AvatarCatalog<string>; id: string} | undefined {
	if (typeof source !== 'string') {
	return undefined;
	}
	for (const catalog of CDN_CATALOGS) {
	const id = catalog.getNameFromURL(source);
	if (id) {
	return {catalog, id};
	}
	}
	return undefined;
	}
	function findLocalAvatarForURL(source: unknown): React.FC<SvgProps> | undefined {
	const match = findCatalogMatchForURL(source);
	return match?.catalog.getLocal(match.id);
	}

This is exactly the pattern the generic Avatar component (used everywhere else the agent avatar is displayed, e.g. the avatar picker/preview on the Profile page) relies on to stay network-independent: it resolves the source through getAvatar, then additionally re-checks findLocalAvatarForURL and swaps in the local SVG whenever one exists, so it renders correctly with or without connectivity:

App/src/components/Avatar.tsx

Lines 95 to 105 in 9813012

	const source = isWorkspace ? originalSource : getAvatar({avatarSource: originalSource, accountID: userAccountID, defaultAvatars});
	// Read the color and initials directly from the generated letter-avatar URL.
	const letterAvatarParts = parseLetterAvatarURL(source);
	let optimizedSource = source;
	const localFromCatalog = findLocalAvatarForURL(source);
	if (localFromCatalog) {
	optimizedSource = localFromCatalog;
	}

ShareCodePage only applies an SVG fallback for the workspace/report branch (svgLogo is populated solely inside if (!logo && policy && !policy.avatarURL)), never for the personal-profile branch:

App/src/pages/ShareCodePage.tsx

Lines 129 to 140 in 9813012

	// Default logos (avatars) are SVG and they require some special logic to display correctly
	let svgLogo: React.FC<SvgProps> | undefined;
	let logoBackgroundColor: string | undefined;
	let svgLogoFillColor: string | undefined;
	if (!logo && policy && !policy.avatarURL) {
	svgLogo = getDefaultWorkspaceAvatar(policy.name) || icons.FallbackAvatar;
	const defaultWorkspaceAvatarColors = StyleUtils.getDefaultWorkspaceAvatarColor(policy.id);
	logoBackgroundColor = defaultWorkspaceAvatarColors.backgroundColor?.toString();
	svgLogoFillColor = defaultWorkspaceAvatarColors.fill;
	}

So while online, the CDN request for the bot PNG succeeds and the QR logo renders fine. Once offline, that same CDN request fails (no cache-busting/local fallback is attempted), react-native-qrcode-svg's logo image fails to load, and the center of the QR code is left empty—matching the reported repro exactly.

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

Resolve the personal avatar to its local catalog SVG first (same lookup already used by Avatar.tsx), and only fall back to the CDN logo URL when no local SVG exists (e.g. uploaded photos or generated letter avatars, which aren't catalog-backed).

App/src/pages/ShareCodePage.tsx

Line 39 in 9813012

import {getAvatarURL} from '@libs/UserAvatarUtils';

import {getAvatarURL} from '@libs/UserAvatarUtils';
import {findLocalAvatarForURL} from '@libs/Avatars/AvatarLookup';

App/src/pages/ShareCodePage.tsx

Lines 125 to 140 in 9813012

	const logo = isReport
	? getLogoForWorkspace(report, policy)
	: (getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, accountID: currentUserPersonalDetails?.accountID}) as ImageSourcePropType);
	// Default logos (avatars) are SVG and they require some special logic to display correctly
	let svgLogo: React.FC<SvgProps> | undefined;
	let logoBackgroundColor: string | undefined;
	let svgLogoFillColor: string | undefined;
	if (!logo && policy && !policy.avatarURL) {
	svgLogo = getDefaultWorkspaceAvatar(policy.name) || icons.FallbackAvatar;
	const defaultWorkspaceAvatarColors = StyleUtils.getDefaultWorkspaceAvatarColor(policy.id);
	logoBackgroundColor = defaultWorkspaceAvatarColors.backgroundColor?.toString();
	svgLogoFillColor = defaultWorkspaceAvatarColors.fill;
	}

const personalAvatarSvgLogo = !isReport ? findLocalAvatarForURL(currentUserPersonalDetails?.avatar) : undefined;

const logo = isReport
    ? getLogoForWorkspace(report, policy)
    : personalAvatarSvgLogo
        ? undefined
        : (getAvatarURL({
              avatarSource: currentUserPersonalDetails?.avatar,
              accountID: currentUserPersonalDetails?.accountID,
          }) as ImageSourcePropType);

// Default logos (avatars) are SVG and they require some special logic to display correctly
let svgLogo: React.FC<SvgProps> | undefined = personalAvatarSvgLogo;
let logoBackgroundColor: string | undefined;
let svgLogoFillColor: string | undefined;

if (!logo && !svgLogo && policy && !policy.avatarURL) {
    svgLogo = getDefaultWorkspaceAvatar(policy.name) || icons.FallbackAvatar;
    const defaultWorkspaceAvatarColors = StyleUtils.getDefaultWorkspaceAvatarColor(policy.id);
    logoBackgroundColor = defaultWorkspaceAvatarColors.backgroundColor?.toString();
    svgLogoFillColor = defaultWorkspaceAvatarColors.fill;
}

This keeps the fix scoped and safe across the edge cases in play:

• Offline correctness: findLocalAvatarForURL resolves a bundled SVG synchronously, with no network dependency, so the agent avatar keeps rendering in the QR code whether the device is online or offline—satisfying the "local SVG fallback" behavior called out in the Expected Result.
• User (Season F1) catalog avatars: findLocalAvatarForURL looks up both the USER_AVATARS and AGENT_AVATARS catalogs, so premium/default "User" avatars picked from the same picker get the identical offline-safe treatment for free, keeping behavior consistent across both catalog types.
• Uploaded photos and generated letter avatars are unaffected: Neither is registered in the catalogs, so findLocalAvatarForURL returns undefined for them and the code falls through to the existing getAvatarURL CDN path exactly as before—no behavior change or regression for those avatar types.
• Workspace/report QR codes are untouched: The isReport branch and its existing getLogoForWorkspace/default-workspace-avatar fallback are unchanged; personalAvatarSvgLogo is only computed when !isReport.
• No dual-rendering: logo is explicitly set to undefined whenever a local SVG is found, preserving the existing mutual exclusivity between logo and svgLogo so QRCode/react-native-qrcode-svg never receives both a raster URL and an SVG logo at once.
• Cross-platform: findLocalAvatarForURL and SVG rendering are the same code path Avatar.tsx already uses on Web, iOS, and Android, so no new platform-specific branching is introduced.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

When an agent profile avatar is selected, the profile avatar flow saves the selected catalog avatar URI into personal details (AgentProfileAvatar resolves the selected customExpensifyAvatarID to a URI and passes it to updateAvatar, which stores it as avatar/avatarThumbnail) (AgentProfileAvatar.tsx#L23-L35, PersonalDetails.ts#L361-L378). Normal avatar rendering can convert catalog-backed avatar URLs, including agent avatars, back to local SVG assets via getAvatar()/findLocalAvatarForURL() (UserAvatarUtils.ts#L341-L351, AvatarLookup.ts#L8-L27, AgentAvatarCatalog.ts#L14-L23). However, ShareCodePage uses getAvatarURL() for the account QR logo, which intentionally returns the catalog CDN URL instead of the local SVG (ShareCodePage.tsx#L125-L127, UserAvatarUtils.ts#L365-L373). That CDN URL is then passed as logo to the QR component (ShareCodePage.tsx#L158-L168, QRShare/index.tsx#L84-L94), so after clearing cache and going offline the QR library cannot load the remote center image and the agent avatar disappears, even though the local SVG fallback exists.

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

In ShareCodePage, resolve the current user’s avatar with getAvatar() instead of getAvatarURL() for the non-report share-code path. Use useDefaultAvatars() to provide the required default avatar assets, then split the resolved value by type: if it is a string, keep passing it as logo; if it is a React SVG component, pass it as svgLogo and leave logo undefined. QRCode already supports SVG center logos through logoSVG (QRCode.tsx#L26-L40, QRCode.tsx#L90-L99), so this keeps uploaded/remote avatars working while making catalog-backed agent avatars render from the local SVG asset offline.

Keep the existing workspace/report QR behavior unchanged. The workspace default-avatar branch already uses svgLogo only when there is no logo (ShareCodePage.tsx#L129-L140), so the account-avatar fix should follow the same pattern and only apply to the !isReport case.

What alternative solutions did you explore? (Optional)

I considered adding a QR-specific image fallback or preloading the CDN image, but that would still make the QR logo depend on network/cache state. Reusing the existing catalog-to-local-avatar resolution is smaller and matches how avatars are already rendered elsewhere in the app.

[yusufdeveloper2903]

Proposal

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

On the profile Share page, when the current user has an Agent (bot) avatar selected, the avatar rendered in the center of the QR code disappears as soon as the device goes offline. Online it shows correctly; offline the QR code is left with no center logo.

What is the root cause of that problem?

The Share page renders the QR center logo from a remote CloudFront URL, so the moment the network is gone there is nothing to load.

For the personal-profile case, ShareCodePage.tsx:125-127 computes the logo with getAvatarURL(...) and passes the result to QRShareWithDownload via the logo prop:

const logo = isReport
    ? getLogoForWorkspace(report, policy)
    : (getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, accountID: currentUserPersonalDetails?.accountID}) as ImageSourcePropType);

Agent avatars are catalog-backed — every bot-avatar--* entry in AgentAvatarCatalog.ts:14-21 carries both a CDN url and a bundled local SVG component. For catalog-backed sources, getAvatarURL deliberately returns the CDN URL (match.catalog.getURL(match.id)), not the local asset. That URL flows into the QR library's raster logo slot in QRCode.tsx:90-103, which is a plain network image — offline it silently fails and the center of the QR code goes blank.

The svgLogo path that would fix this already exists and is offline-safe: QRShare forwards svgLogo to the library's logoSVG slot, which renders a bundled React.FC<SvgProps> with no network dependency. But that path is wired up only for default workspace avatars (ShareCodePage.tsx:130-140) — personal avatars never use it, even though AvatarLookup can resolve any catalog URL to its local SVG in one call via findLocalAvatarForURL.

History of how we got here:

• Agent avatars were added to the Share QR by PR #95901 (commit 21c3ba892b3), which fixed the bot-avatar CDN path so the avatar would finally render — but rendered it through the remote URL, inheriting the offline gap.
• The catalog lookup layer that makes the local SVG trivially reachable landed in c9fe1b0e88c ("Simplify avatar catalog lookup layer") — getAvatar/findLocalAvatarForURL return the bundled SVG for exactly these sources — yet the Share page still calls getAvatarURL and only ever hands the QR a URL for personal avatars.

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

Primary fix (root cause): for the personal-profile QR, resolve a catalog-backed avatar (Agent or default User) to its bundled local SVG and route it through the offline-safe svgLogo prop, falling back to the URL logo only for genuinely uploaded avatars.

In ShareCodePage.tsx:

// Catalog-backed avatars (agent + default user) have a bundled SVG. Prefer it so the QR center
// logo renders from a local asset instead of a network image — visible even offline.
const localAvatarSvg = !isReport ? findLocalAvatarForURL(currentUserPersonalDetails?.avatar) : undefined;

const logo = isReport
    ? getLogoForWorkspace(report, policy)
    : localAvatarSvg
      ? undefined // let svgLogo drive the center logo
      : (getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, accountID: currentUserPersonalDetails?.accountID}) as ImageSourcePropType);

let svgLogo: React.FC<SvgProps> | undefined = localAvatarSvg;

The existing default-workspace block (if (!logo && policy && !policy.avatarURL)) is untouched — it only runs for reports, so it never collides with the personal localAvatarSvg. Because svgLogo now carries the value, we leave svgLogoFillColor/logoBackgroundColor unset for personal avatars: bot avatars are full-color SVGs and must not be tinted.

Why this fixes it:

• Agent avatar → offline: findLocalAvatarForURL maps the bot-avatar--* CDN URL to its bundled BotAvatar* SVG; it renders through logoSVG with zero network calls, so it stays visible.
• Agent avatar → online: identical local SVG renders — pixel-consistent with offline, no flicker on the first load either.
• Default user avatar → offline: same catalog path resolves the default-avatar_X SVG, so the long-standing offline gap for those closes too.
• Uploaded (custom) avatar: findLocalAvatarForURL returns undefined, so we keep the URL logo exactly as today — uploads are inherently remote and unchanged.

Result: the selected Agent avatar (and any catalog avatar) stays rendered in the center of the Share QR code whether the device is online or offline.

What alternative solutions did you explore? (Optional)

• Swap getAvatarURL for getAvatar and keep passing it as logo. getAvatar does return the local SVG for catalog avatars, but the QR logo slot is a raster/ImageSourcePropType image prop — handing it a React.FC<SvgProps> won't render as the center logo. The SVG must go through svgLogo/logoSVG, which is precisely what the primary fix does; simply switching the helper is insufficient.
• Cache/prefetch the avatar PNG for offline use (e.g. persist the last-loaded image). This is a heavier, storage-backed workaround that still fails on a cold cache (first offline open) and duplicates data we already ship — the bundled SVG is the single source of truth and is always available. Using it is strictly better.
• Make getAvatarURL return the local SVG for catalog avatars. That would be misdirected — getAvatarURL exists specifically to produce a URL string (sharing, external display, download filenames); changing its contract would ripple to every other caller. The offline gap is a Share-page rendering choice, so the fix belongs at the Share page where the svgLogo path already lives.

[aswin-s]

Note: This proposal is not a duplicate. It identifies a deeper root cause rather than the surface symptom.

Proposal

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

When a user with an agent avatar opens the Share page while offline (Android app / Windows Chrome), the avatar disappears from the center of the QR code. Expected: the previously selected agent avatar remains visible by using the local SVG fallback that ships with the app.

What is the root cause of that problem?

In src/pages/ShareCodePage.tsx:125-127, the personal-avatar branch resolves logo via getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, accountID}). getAvatarURL at src/libs/UserAvatarUtils.ts:365-374 deliberately returns the remote CloudFront URL for a catalog-backed avatar (match.catalog.getURL(match.id)) rather than the local SVG asset — so agent avatars are always fetched over the network. Offline, that request fails and the QR center goes blank. The sibling helper getAvatar at UserAvatarUtils.ts:341-352 already resolves catalog URLs to a local asset via findLocalAvatarForURL, and QRShareWithDownload already accepts an svgLogo prop (populated only for default workspace avatars today at ShareCodePage.tsx:134-140) — the agent-avatar case never takes that SVG path.

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

1. In src/pages/ShareCodePage.tsx:125-140, for the non-report branch resolve the avatar with getAvatar(...) (which returns the local SVG for catalog-backed user/agent avatars via findLocalAvatarForURL) instead of getAvatarURL(...).
2. When the resolved value is a component (SVG asset from the catalog), route it into the existing svgLogo prop on QRShareWithDownload instead of logo, mirroring the workspace-default handling already in place at lines 134-140. Keep logo for string URLs (uploaded avatars).
3. Preserve the ratio/margin selection currently keyed on logo === expensifyLogo; apply DEFAULT_LOGO_* ratios whenever an svgLogo is used for user/agent avatars.
4. No change required to AgentAvatarCatalog.ts (PR Fix agent avatar CDN URL path in Share Code QR #95901) — the CDN path fix stands; this issue is that the QR-code path never uses the local SVG in the first place.

What alternative solutions did you explore? (Optional)

[lorretheboy]

Note: This isn't a duplicate — the proposal it was flagged against was posted before the Help Wanted label (2026-07-14T17:08:57Z, before 2026-07-14T17:10:49Z), so it isn't a valid earlier proposal.

Proposal

What is the root cause of that problem?

For the personal Share page, the QR logo is built with getAvatarURL, which for a catalog (agent) avatar returns the remote CloudFront PNG URL:

App/src/pages/ShareCodePage.tsx

Lines 125 to 127 in 1577e12

	const logo = isReport
	? getLogoForWorkspace(report, policy)
	: (getAvatarURL({avatarSource: currentUserPersonalDetails?.avatar, accountID: currentUserPersonalDetails?.accountID}) as ImageSourcePropType);

App/src/libs/UserAvatarUtils.ts

Lines 369 to 372 in 1577e12

	const match = findCatalogMatchForURL(avatarSource);
	if (match) {
	return match.catalog.getURL(match.id);
	}

That URL is passed straight to react-native-qrcode-svg as a network image (logo → logoSVG/logo props). Offline, with the cache cleared, the fetch fails and the library renders nothing in the QR center. The bundled local SVGs for agent avatars exist (AGENT_AVATARS local entries) and every other avatar surface resolves them at render time via getAvatar/findLocalAvatarForURL, but the Share QR surface never goes through that lookup — so no local fallback exists here. PR #95901 only fixed the CDN path (broken image online); it didn't add the offline fallback its offline test step assumed, so the offline case remained broken.

App/src/libs/Avatars/AvatarLookup.ts

Lines 24 to 27 in 1577e12

	function findLocalAvatarForURL(source: unknown): React.FC<SvgProps> | undefined {
	const match = findCatalogMatchForURL(source);
	return match?.catalog.getLocal(match.id);
	}

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

In ShareCodePage, for the non-report case, resolve the avatar to the bundled asset first: call findLocalAvatarForURL(currentUserPersonalDetails?.avatar) and, when it returns a component, pass it as svgLogo to QRShareWithDownload (the prop already exists and is wired through to the QR library) instead of setting logo. Only fall back to getAvatarURL for uploaded avatars that have no local asset. Pseudo-code:

const localAvatar = !isReport ? findLocalAvatarForURL(currentUserPersonalDetails?.avatar) : undefined;
const logo = isReport ? getLogoForWorkspace(report, policy) : localAvatar ? undefined : getAvatarURL(...);
// pass svgLogo={svgLogo ?? localAvatar}

This makes catalog avatars (agent and preset user avatars alike) render from the bundle with no network request, so they work identically online and offline.

What alternative solutions did you explore? (Optional)

Using getAvatar (which already returns local SVG for catalog avatars, URL otherwise) and branching on whether the result is a string — equivalent, slightly less explicit. A deeper fix (making the QR image component fall back to a local asset on load error) touches react-native-qrcode-svg internals and isn't worth it when the local asset is already known up front.