[$250] [HR Import] Handle Sync errors gracefully

[grgia]

TBD

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057501395818474523
• Upwork Job ID: 2057501395818474523
• Last Price Increase: 2026-05-21

[MelvinBot]

Proposal

What is the root cause of that problem?

HR sync errors are not surfaced gracefully because several error-propagation paths that exist for accounting connections (QBO, Xero, etc.) are missing for HR connections (Gusto, MergeHR, Zenefits):

1. No brick road indicator on the HR menu item — The HR entry in WorkspaceInitialPage.tsx:268-277 has no brickRoadIndicator, unlike the Accounting entry which checks hasSyncError. Users must navigate into the HR page to discover a sync failure.

2. Global policy indicator ignores HR connections — usePolicyIndicatorChecks.ts:28-33 only passes ACCOUNTING_CONNECTION_NAMES to shouldShowSyncError(), so HR sync errors never show red dots on the workspace list.

3. API-call failures are silent — When the sync API call itself fails (network error), the failureData in syncConnection() only clears the spinner (POLICY_CONNECTION_SYNC_PROGRESS → null). It does not set lastSync.isSuccessful = false, so the user sees the spinner disappear with zero feedback.

4. Disconnected MergeHR cards suppress errors — utils.ts:235-247 hardcodes hasError: false for disconnected providers, silently swallowing errors during initial setup or transient states.

5. No sync-results modal for MergeHR/Zenefits — Only Gusto has a GustoSyncResultsModal; MergeHR and Zenefits provide no post-sync summary.

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

1. Add brickRoadIndicator to the HR menu item in WorkspaceInitialPage.tsx — mirror the accounting entry's hasSyncError check but using HR connection names.

2. Include HR connections in usePolicyIndicatorChecks — pass both ACCOUNTING_CONNECTION_NAMES and HR_CONNECTION_NAMES (or a combined set) to shouldShowSyncError() so HR errors bubble up to the workspace list.

3. Set error state on API-call failure — in syncConnection() and syncMergeHR(), the failureData should also write lastSync.isSuccessful = false and lastSync.errorDate so hasSynchronizationErrorMessage() detects the failure.

4. Surface errors for disconnected MergeHR cards — instead of hardcoding hasError: false, propagate the actual error state so users see what went wrong.

5. Add sync-results modals for MergeHR and Zenefits — either generalize GustoSyncResultsModal into a shared HRSyncResultsModal or create provider-specific equivalents.

What alternative solutions did you explore?

• Could rely solely on backend Pusher events for error state (current approach for the "happy path"), but this doesn't cover network/API failures where the Pusher event never arrives. The client-side failureData must set explicit error state as a fallback.
• Could add a timeout-based error (if spinner persists past SYNC_STAGE_TIMEOUT_MINUTES), but this is a poor UX — users shouldn't wait for a timeout when the API call already returned an error.

Related issues and investigation details

Related open issues:

• [Due for payment 2026-07-13] [HR Import] Error states + reconnect prompt on the HR card [F12] #90605 — [HR Import] Error states + reconnect prompt on the HR card [F12] (covers isAuthenticationError reconnect flow specifically)
• [Gusto] [Bug] Update GustoSyncResult to match IS payload shape from JOB_DONE event #90573 — [Gusto] Update GustoSyncResult to match IS payload shape

Key code paths:

• Error detection: hasSynchronizationErrorMessage() checks lastSync.isSuccessful === false and errorDate
• HR card state derivation: getHRCardState() derives hasError from hasSynchronizationErrorMessage()
• Error display: HRProviderCard.tsx:53-57 shows inline red error text with backend message
• Policy-level indicator: getPolicyBrickRoadIndicatorStatus only checks accounting connections

---

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.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-21 16:44:28 UTC.

Replaces my earlier proposal: current origin/main has since landed the per-provider HR page card refactor, so the old Gusto-only HR-page defect is stale. The remaining issue is the top-level workspace indicator plumbing still scanning accounting connections only.

Proposal

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

When an HR import sync fails, admins should be guided to the workspace HR area from the top-level workspace surfaces instead of only seeing the failure after they already open the HR settings page.

The current HR page can render provider-level sync errors, but the workspace list, workspace initial page, and global policy indicator checks still miss HR sync failures because those top-level checks are scoped to accounting connections.

What is the root cause of that problem?

The shared sync-error predicate already supports any connection name. It returns true when the selected connection's last sync failed and has an error date, and it is used through the generic shouldShowSyncError wrapper.

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

Lines 278 to 284 in 118a7ac

	function hasSynchronizationErrorMessage(policy: OnyxEntry<Policy>, connectionName: PolicyConnectionName, isSyncInProgress: boolean): boolean {
	const connection = policy?.connections?.[connectionName];
	if (isSyncInProgress || isEmptyObject(connection?.lastSync) || connection?.lastSync?.isSuccessful !== false || !connection?.lastSync?.errorDate) {
	return false;
	}
	return true;

App/src/libs/PolicyUtils.ts

Lines 240 to 242 in 118a7ac

	function shouldShowSyncError(policy: OnyxEntry<Policy>, isSyncInProgress: boolean, connectionNames?: readonly ConnectionName[]): boolean {
	const connectionsToCheck = connectionNames ?? (Object.keys(policy?.connections ?? {}) as ConnectionName[]);
	return isPolicyAdmin(policy) && connectionsToCheck.some((connection) => !!hasSynchronizationErrorMessage(policy, connection, isSyncInProgress));

The HR page now derives each provider card from the provider's connection name and uses that same failure predicate, then renders a generic provider-specific error on the card. So the row-level HR page path is no longer the broken part.

App/src/pages/workspace/hr/utils.ts

Lines 88 to 100 in 118a7ac

	/** Derives the runtime state (connected, syncing, errors, last sync date) for a single HR provider on a given policy. */
	function getHRCardState({policy, connectionName, connectionSyncProgress, getLocalDateFromDatetime, mergeSlug}: GetHRCardStateParams) {
	const isSyncInProgress = connectionSyncProgress?.connectionName === connectionName && isConnectionInProgress(connectionSyncProgress, policy);
	const connectedProvider = getConnectedHRProvider(policy);
	const isConnected = connectedProvider?.connectionName === connectionName && (!mergeSlug || connectedProvider.mergeSlug === mergeSlug);
	const connection = policy?.connections?.[connectionName];
	const syncProgress = connectionSyncProgress?.connectionName === connectionName ? connectionSyncProgress : undefined;
	const successfulDate = getIntegrationLastSuccessfulDate(getLocalDateFromDatetime, connection, syncProgress);
	const hasError = hasSynchronizationErrorMessage(policy, connectionName, !!isSyncInProgress);
	const lastSyncErrorMessage = hasError ? (connection?.lastSync?.errorMessage ?? undefined) : undefined;

App/src/pages/workspace/hr/HRProviderCard.tsx

Lines 53 to 57 in 118a7ac

	let lastSyncErrorMessage: string | undefined;
	if (card.hasError) {
	const genericError = translate('workspace.hr.syncError', card.displayName);
	lastSyncErrorMessage = card.lastSyncErrorMessage ? `${genericError} ("${card.lastSyncErrorMessage}")` : genericError;
	}

App/src/pages/workspace/hr/HRProviderCard.tsx

Lines 122 to 130 in 118a7ac

	<MenuItem
	title={card.displayName}
	icon={cardIcon}
	iconType={CONST.ICON_TYPE_AVATAR}
	wrapperStyle={[styles.ph0, styles.pv2, !!lastSyncErrorMessage && styles.pb0]}
	interactive={false}
	description={connectionDescription}
	errorText={lastSyncErrorMessage}
	errorTextStyle={styles.mt5}

The remaining defect is that the top-level workspace checks still pass only accounting connection names. WorkspaceInitialPage computes hasSyncError from ACCOUNTING_CONNECTION_NAMES, uses it only for the Accounting row, and gives the HR row no brick-road indicator at all.

App/src/pages/workspace/WorkspaceInitialPage.tsx

Lines 142 to 143 in 118a7ac

	const accountingConnectionNames = CONST.POLICY.CONNECTIONS.ACCOUNTING_CONNECTION_NAMES;
	const hasSyncError = shouldShowSyncError(policy, isConnectionInProgress(connectionSyncProgress, policy), accountingConnectionNames);

App/src/pages/workspace/WorkspaceInitialPage.tsx

Lines 256 to 276 in 118a7ac

	if (policyFeatureStates?.[CONST.POLICY.MORE_FEATURES.ARE_CONNECTIONS_ENABLED]) {
	workspaceMenuItems.push({
	translationKey: 'workspace.common.accounting',
	icon: expensifyIcons.Sync,
	action: singleExecution(waitForNavigate(() => Navigation.navigate(ROUTES.POLICY_ACCOUNTING.getRoute(policyID)))),
	brickRoadIndicator: hasSyncError || shouldShowQBOReimbursableExportDestinationAccountError(policy) ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined,
	screenName: SCREENS.WORKSPACE.ACCOUNTING.ROOT,
	sentryLabel: CONST.SENTRY_LABEL.WORKSPACE.INITIAL.ACCOUNTING,
	highlighted: highlightedFeature === CONST.POLICY.MORE_FEATURES.ARE_CONNECTIONS_ENABLED,
	});
	}
	if (policyFeatureStates?.[CONST.POLICY.MORE_FEATURES.IS_HR_ENABLED]) {
	workspaceMenuItems.push({
	translationKey: 'workspace.common.hr',
	icon: expensifyIcons.Users,
	action: singleExecution(waitForNavigate(() => Navigation.navigate(ROUTES.WORKSPACE_HR.getRoute(policyID)))),
	screenName: SCREENS.WORKSPACE.HR,
	sentryLabel: CONST.SENTRY_LABEL.WORKSPACE.INITIAL.HR,
	highlighted: highlightedFeature === CONST.POLICY.MORE_FEATURES.IS_HR_ENABLED,
	});

The same accounting-only scope is used for the workspace-list policy brick-road status and for the global policy indicator hook, even though PolicyUtils already exposes getHRConnectionNames() and CONST.POLICY.CONNECTIONS.HR_CONNECTION_NAMES includes Gusto, Zenefits, and Merge HR.

App/src/libs/PolicyUtils.ts

Lines 518 to 524 in 118a7ac

	function getPolicyBrickRoadIndicatorStatus(policy: OnyxEntry<Policy>, isConnectionInProgress: boolean): ValueOf<typeof CONST.BRICK_ROAD_INDICATOR_STATUS> | undefined {
	if (
	shouldShowEmployeeListError(policy) ||
	shouldShowCustomUnitsError(policy) ||
	shouldShowPolicyErrorFields(policy) ||
	shouldShowSyncError(policy, isConnectionInProgress, getAccountingConnectionNames()) ||
	shouldShowQBOReimbursableExportDestinationAccountError(policy)

App/src/hooks/usePolicyIndicatorChecks.ts

Lines 28 to 33 in 118a7ac

	[CONST.INDICATOR_STATUS.HAS_SYNC_ERRORS]: cleanPolicies.find((cleanPolicy) =>
	shouldShowSyncError(
	cleanPolicy,
	isConnectionInProgress(allConnectionSyncProgresses?.[`${ONYXKEYS.COLLECTION.POLICY_CONNECTION_SYNC_PROGRESS}${cleanPolicy?.id}`], cleanPolicy),
	CONST.POLICY.CONNECTIONS.ACCOUNTING_CONNECTION_NAMES,
	),

App/src/libs/PolicyUtils.ts

Lines 1912 to 1914 in 118a7ac

	function getHRConnectionNames(): HRConnectionName[] {
	return [...CONST.POLICY.CONNECTIONS.HR_CONNECTION_NAMES];
	}

App/src/CONST/index.ts

Lines 3920 to 3921 in 118a7ac

	get HR_CONNECTION_NAMES() {
	return [this.NAME.GUSTO, this.NAME.ZENEFITS, this.NAME.MERGE_HR] as const;

Because of that mismatch, an HR connection can have a failed lastSync that is visible once the admin reaches the HR page, but no top-level red brick road points them there.

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

1. Add a small PolicyUtils helper for workspace-level sync-error scopes, for example getWorkspaceSyncErrorConnectionNames(), that returns both getAccountingConnectionNames() and getHRConnectionNames().

2. Update top-level policy/workspace indicators to use that broader workspace helper:

• getPolicyBrickRoadIndicatorStatus(), so the Workspaces list marks a policy with an HR sync failure.
• usePolicyIndicatorChecks(), so the global workspaces/policy indicator also catches HR sync failures.

3. Keep page-specific scopes separate in WorkspaceInitialPage:

• compute hasAccountingSyncError with accounting connection names and keep it on the Accounting row.
• compute hasHRSyncError with HR connection names and add that brick-road indicator to the HR row.

4. Leave accounting-only pages such as Reports, Categories, Taxes, Tags, and the Accounting page scoped to accounting connections, because those pages should not display unrelated HR import failures.

5. Add focused tests in tests/unit/PolicyUtilsTest.ts covering an admin policy with a failed HR connection, a non-admin policy with the same failure, and the in-progress sync case. If there are component tests for the workspace initial menu, add one assertion that HR sync errors mark the HR row rather than the Accounting row.

Scope boundaries: I would touch src/libs/PolicyUtils.ts, src/hooks/usePolicyIndicatorChecks.ts, src/pages/workspace/WorkspaceInitialPage.tsx, and the focused policy utility tests. I would not change backend HR sync jobs, sync result payloads, accounting page behavior, or the current WorkspaceHRPage/HRProviderCard row-level error rendering. I would also leave the Gusto-specific Members page shortcut alone unless product explicitly wants that shortcut expanded to every HR provider, because the HR page already exposes provider-specific sync actions.

What alternative solutions did you explore? (Optional)

I considered keeping my earlier HR-page generalization proposal, but current main already added getHRCards() and HRProviderCard, which cover Gusto, Zenefits, and Merge HR row-level error rendering. Reworking that path again is no longer the right fix for this issue.

I also considered changing every shouldShowSyncError caller to omit the connectionNames argument so all connections are scanned by default. That would be too broad: accounting-specific pages intentionally pass accounting connection names, and they should not show HR import failures inside accounting-only screens.

No competing human strict proposals were posted after my original comment; the only later comments were Melvin bot assignment/Upwork automation.

[melvin-bot]

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

[melvin-bot]

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

[oqildev]

Proposal

What is the root cause of that problem?

The new HR / Gusto flow was built on top of the same Connection<> and policyConnectionSyncProgress_ data model used by Accounting, but the HR surface never wired any of the existing sync-error handling that Accounting uses. Failure paths therefore fall through silently. Concretely, there are five independent gaps, each one capable of producing a "sync just disappears" or "user gets stuck" symptom:

1. The HR page itself renders nothing about sync state. WorkspaceHRPage only paints the static "Connect" card. It never subscribes to ONYXKEYS.COLLECTION.POLICY_CONNECTION_SYNC_PROGRESS, never reads policy?.connections?.gusto?.lastSync, never calls getSynchronizationErrorMessage, and never calls isAuthenticationError / hasSynchronizationErrorMessage. Even when the backend writes a perfectly correct lastSync: {isSuccessful: false, errorMessage} onto the gusto connection, the HR page keeps showing the cheerful "Connect" CTA.

2. openPolicyHRPage swallows API failures. The failureData block on openPolicyHRPage only flips policyHasConnectionsDataBeenFetched to false (the same bit the optimistic step sets). It does not call setConnectionError, does not populate lastSync.errorMessage, and does not toggle any user-visible flag, so a failed OpenPolicyHRPage is indistinguishable from a successful one that returned an empty connection.

3. The user-facing copy has no Gusto branch. workspace.accounting.syncError switches on the connection name and falls through to the generic "Can't connect to integration" for Gusto. That string also lives under the workspace.accounting.* namespace, which is the wrong place for an HR connection. Worse, workspace.hr.syncStageName only has cases for the four Gusto stages plus jobDone — any other stage value (e.g. a generic connectionFailed or paused stage emitted by IS) renders the literal string Translation missing for stage: … to the admin.

4. isConnectionInProgress silently drops the sync after 20 minutes. Lines 344–359 of connections/index.ts hide the sync banner once differenceInMinutes(now, timestamp) >= 20, regardless of whether the job actually finished, errored, or was cancelled. With Gusto having no explicit setConnectionError writer on the HR side (see gap Fix spaces #2 + Fix babel build on master #5), a sync that stalls in gustoSyncImportEmployees just vanishes — to the user it looks like the spinner disappeared and "nothing happened."

5. No data slot exists for a top-level Gusto error. GustoSyncResult only carries added/removed/skipped[] — there is no error, errorCode, or failedStages[]. PolicyConnectionSyncProgress similarly only stores stageInProgress + timestamp + result, with no hook for a failed JOB_DONE. And GustoConnectionConfig only has errorFields for config form errors (approvalMode, finalApprover) — there is no place for a "sync was rejected because the Gusto OAuth scope is missing" type of message to live. So even if IS sends us a JOB_DONE with a failure payload, we have nowhere structured to put it and nothing on the page that would read it.

There is also a downstream brick-road consequence: WorkspaceInitialPage calls shouldShowSyncError with accountingConnectionNames, so the red dot on the HR feature row in the workspace LHN will never light up for a Gusto failure — only quickbooksOnline / xero / netsuite / intacct / qbd / certinia are checked.

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

Fix layer is the HR page + the action layer that owns the Gusto sync, not the shared connections/index.ts selectors. The selectors are correct — they iterate any connection name they're handed. The bug is that the HR page never asks the questions and the action layer never writes the answers.

1. Surface sync state on WorkspaceHRPage. Add Onyx subscriptions for ${ONYXKEYS.COLLECTION.POLICY_CONNECTION_SYNC_PROGRESS}${policyID} and use the existing helpers — isConnectionInProgress, hasSynchronizationErrorMessage, isAuthenticationError, getSynchronizationErrorMessage — exactly the way PolicyAccountingPage lines 100–129 does. Replace the static MenuItem with one that:

   • shows an ActivityIndicator + the translated syncStageName(stageInProgress) while syncing,
   • renders errorText={synchronizationError} with shouldShowRedDotIndicator when lastSync.isSuccessful === false,
   • when isAuthenticationError(policy, 'gusto') is true, offers a "Reconnect Gusto" overflow action that re-runs the OAuth flow (mirrors shouldShowEnterCredentials at PolicyAccountingPage line 113),
   • otherwise offers a "Sync now" overflow that calls a new syncGusto(policy) action.

2. Wire syncGusto as a real action. The SYNC_GUSTO read command already exists in API/types.ts line 1194 but is never called. Extend getSyncConnectionParameters with a GUSTO case that returns {readCommand: READ_COMMANDS.SYNC_GUSTO, stageInProgress: CONST.POLICY.CONNECTIONS.SYNC_STAGE_NAME.STARTING_IMPORT_GUSTO}. That immediately makes syncConnection work for Gusto and gives us the optimistic policyConnectionSyncProgress_ write that issue #90419 is asking for separately — so the spinner appears immediately.

3. Make openPolicyHRPage set a real connection error on failure. In PolicyConnections.ts lines 49–55, the failureData block should also Onyx.MERGE into policy.connections.gusto.lastSync with {isSuccessful: false, errorDate: new Date().toISOString(), errorMessage: <translated generic>} — i.e., do what setConnectionError does. Without this, the HR page has no signal at all that the read failed.

4. Add a Gusto branch to user-facing copy, and move it out of the accounting namespace.

   • Add case CONST.POLICY.CONNECTIONS.NAME.GUSTO: return "Can't connect to Gusto" to workspace.accounting.syncError (and rename / re-export from workspace.common.syncError so HR can call it without reaching into the accounting bucket — workspace.common.authenticationError already lives in common for exactly this reason).
   • Replace the default: branch in workspace.hr.syncStageName — the literal Translation missing for stage: … should not ship to users. Either render a neutral "Syncing Gusto" string or hide the row entirely when the stage is unknown.

5. Carry the backend error on the sync payload. Extend GustoSyncResult with an optional error?: {code: string; message: string} and surface it in PolicyConnectionSyncProgress.result so that a JOB_DONE carrying a failure can be rendered in the same errorText slot. Have the Pusher JOB_DONE handler in App.ts (the same place that consumes IS sync results today) detect result.error and call setConnectionError(policyID, 'gusto', result.error.message) so the existing hasSynchronizationErrorMessage path lights up.

6. Add Gusto to the brick-road check. Update WorkspaceInitialPage.tsx line 138–139 to also pass CONST.POLICY.CONNECTIONS.HR_CONNECTION_NAMES to shouldShowSyncError so the HR feature row gets a red dot when Gusto fails. The constant already exists at CONST/index.ts line 3729–3731.

7. Handle the 20-minute stall. Today the only way isConnectionInProgress returns false is the timeout. For HR, when isConnectionInProgress returns false and there's no fresh lastSync.successfulDate, the page should call setConnectionError(policyID, 'gusto', translate('workspace.common.syncTimeout')) so the user sees "We couldn't finish syncing Gusto — try again." rather than the spinner just vanishing.

Edge cases to cover:

• Offline: the "Sync now" / "Reconnect" buttons must disable via useNetwork().isOffline (same pattern as PolicyAccountingPage). The optimistic policyConnectionSyncProgress_ write should not be queued indefinitely — gate syncGusto on !isOffline so the spinner doesn't show with no network and no recovery.
• Optimistic rollback: when failureData from SYNC_GUSTO runs (syncConnection lines 157–163), it currently SETs the sync progress to null but does nothing to lastSync. Add a sibling MERGE into policy.connections.gusto.lastSync so the failed attempt is recorded and renders as an error rather than silently disappearing.
• Empty / not-yet-connected state: the new error UI must guard on !!policy?.connections?.gusto — for a workspace that has never connected Gusto, the page should still show the original "Connect" CTA, not an error banner.
• Approval-mode write failures: GustoConnectionConfig.errorFields already carries per-field errors for approvalMode / finalApprover. Once the Gusto settings page is built, those should render via errorText on each form row — separate from lastSync.errorMessage (which is the sync error, not the config-write error). The two error channels must not be merged.

What alternative solutions did you explore? (Optional)

• Just throw a generic toast on every Gusto failure. Rejected: it doesn't address the auth-error vs sync-error distinction (isAuthenticationError decides between "Reconnect" and "Sync now" overflow actions), and a toast is dismissable — sync state needs to be inspectable later from the HR page, otherwise an admin who navigates away can never tell why the integration is unhealthy.

• Reuse PolicyAccountingPage.tsx directly with a feature flag. Rejected: that page is heavily branched on accountingIntegrations, tenants, NetSuite subsidiaries, Sage entities, Expensify Card reconciliation, etc. — none of which apply to HR. The cleaner path is to extract a small ConnectedIntegrationCard component covering "spinner / error / overflow menu / red-dot" so both the Accounting and HR pages share it, but that extraction is out of scope for this bug and should be tracked separately.

• Put all Gusto sync error UI on WorkspaceInitialPage instead of WorkspaceHRPage. Rejected: the initial page only shows aggregate red-dot indicators; the place a user goes to understand and act on a sync failure is the feature's own page. Both should reflect the state — initial page for at-a-glance, HR page for detail + recovery — which is exactly the pattern Accounting follows.

• Treat the missing default in workspace.hr.syncStageName as the only bug. Rejected: fixing the fallback text alone hides the symptom but doesn't address that the page never reads sync state at all, never sees isSuccessful === false, and never renders a recovery affordance. That string only appears when a stage is in progress — it can't help an admin whose sync silently failed.

Deferred out of scope (track separately, both already have issues):

• #90573 — GustoSyncResult payload-shape mismatch with IS JOB_DONE. The error field proposed above should be added in the same change that lands [Gusto] [Bug] Update GustoSyncResult to match IS payload shape from JOB_DONE event #90573 to avoid two churn passes on GustoSyncResult.
• #90419 — sync spinner not appearing immediately on approval-mode toggle. Solved as a side-effect of step Fix spaces #2 (wiring syncGusto through syncConnection's optimistic policyConnectionSyncProgress_ write).

[KJ21-ENG]

Updated my proposal - current main already fixed the HR page row; remaining fix is top-level HR sync indicators.

[lxyct825-ops]

Proposal

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

[$250] [HR Import] Handle Sync errors gracefully

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150