[Sentry: APP-J4D] Web company-cards import mapping crash — undefined rows .at()

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-J4D

Impact (snapshot at filing)

• Users (total since first seen): 3
• Events: 59
• Users (last 7d): 3
• First seen: 2026-07-21
• Last seen: 2026-07-23
• Platform: web
• App version(s): 9.4.42-1
• Affected route(s): /workspaces/:policyID/company-cards/add-card-feed/import/mapping
• Mechanism: auto.browser.global_handlers.onunhandledrejection

Stack trace (top frames)

Workspace company-cards import mapping handler
  n.at(0) when n is undefined
useSingleExecution/index.ts onPressHandler
BaseGenericPressable onPressHandler

Suspected cause

Company card CSV import mapping assumes parsed row data exists; submitting with missing/invalid import rows calls .at() on undefined.

Reproduction

Unknown — see Sentry events on company-cards import mapping screen.

Related

• Sibling Sentry IDs: none
• Prior GH issues: none

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081739721273328381
• Upwork Job ID: 2081739721273328381
• Last Price Increase: 2026-07-27

Issue Owner

Current Issue Owner: @yusufdeveloper2903

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

Proposal

What is the root cause of that problem?

Pressing Import on the company-cards CSV mapping screen runs the async importTransactions handler, which transposes the column-major spreadsheet back into rows:

const columns = spreadsheet?.data ?? [];
for (let rowIndex = 0; rowIndex < (columns.at(0)?.length ?? 0); rowIndex++) {
    const row: string[] = [];
    for (const column of columns) {
        row.push(column.at(rowIndex) ?? '');   // 💥 throws when `column` is undefined
    }
    ...
}

The ?? '' guards only the result of .at(), not the receiver. If any element of spreadsheet.data is undefined (a sparse/hole array), column.at(rowIndex) throws Cannot read properties of undefined (reading 'at'). On the first iteration rowIndex === 0, so the runtime call is literally column.at(0) — exactly the n.at(0) (n undefined) frame Sentry reports. Because importTransactions is async and its promise isn't caught by the pressable, the throw surfaces as the reported unhandled rejection (onunhandledrejection).

This is the only .at() on the onPress path whose receiver is unguarded. The row.at(...) calls in buildOptimisticCompanyCardCSVTransactions are safe (rows come from csvData.map(row => [...row]), always dense), and columns.at(0) is safe (columns is always an array via ?? []).

Evidence & investigation details

Crash site (current main): CompanyCardsImportedPage.tsx:197-200. The crash-time version (v9.4.42-1, commit 70138e9d9) is byte-identical apart from line numbers.

Not yet fixed: The commits that landed right around the last-seen date — a9bb94c1e (2026-07-23, add optional Card Name column), 9ea8431b0 and 4d2816ec1 (2026-07-24) — only touch validate() / the empty-value check. None add a guard to the .at() loop.

How a hole gets into spreadsheet.data (lower confidence): setSpreadsheetData writes a dense array via Onyx.set, and every other writer only merges columns / containsHeader or sets data: null. We could not prove from code alone how an undefined element enters data at runtime — the most plausible explanation is an Onyx array rehydration / stale partial-state artifact after re-entering the mapping page. The defensive guard below fixes the crash regardless of the exact trigger. Production logs can't reveal the array shape, so this trigger is inferred, not proven.

Sibling latent bug (different route, not this Sentry ID): ImportSpreadsheet.ts:181 column.at(0)?.trim() in applySavedColumnMappings has the same unguarded-receiver pattern, reachable from the Wallet TransactionsImportedPage useEffect.

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

Guard the receiver, not just the result, in the transpose loop in importTransactions:

• Change column.at(rowIndex) ?? '' → column?.at(rowIndex) ?? '' at CompanyCardsImportedPage.tsx:200.

This turns a hole into an empty string instead of throwing. Optionally also drop holes up front (const columns = (spreadsheet?.data ?? []).filter(Boolean);) and apply the same column?.at(0) guard at ImportSpreadsheet.ts:181 to close the sibling Wallet-route crash.

What alternative solutions did you explore? (Optional)

Investigate how spreadsheet.data ends up sparse and prevent the hole at the source (e.g. rebuild data densely before import, or add instrumentation to capture the array shape). This is worth doing as a follow-up to find the true trigger, but the receiver guard above is the minimal, safe fix that stops the crash now.

---

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

IMPORTED_SPREADSHEET.data is typed as a rectangular string[][], but the transpose that produces it can leak a sparse array with a missing (undefined) whole column, and the company‑cards import loop is the one consumer that walks into that hole.

Trace, starting from the file upload:

1. The file is parsed in ImportSpreadsheet.tsx with XLSX.utils.sheet_to_json(worksheet, {header: 1, blankrows: false, raw: true}). With header: 1 and no defval, SheetJS returns rows as sparse arrays — a blank/absent interior cell is left as an array hole, not undefined. The next line, data.map((row) => row.map((cell) => …)), does not densify them: Array.prototype.map skips holes and re‑emits them, so formattedSpreadsheetData rows stay sparse.

2. That data flows into setSpreadsheetData, whose transpose is:

App/src/libs/actions/ImportSpreadsheet.ts

Lines 37 to 40 in 557846e

	const numColumns = firstRow.length;
	// Transpose data from row-major to column-major format
	const transposedData: string[][] = firstRow.map((_, colIndex) => data.map((row) => String(row.at(colIndex) ?? '')));

firstRow = data.at(0) is the header row. If it is sparse with a hole at a column index j > 0 (e.g. a sheet with headers in columns A and C but a blank column B → ["Card", <hole>, "Amount"]), then firstRow.map((_, colIndex) => …) does not invoke the callback for hole j, so transposedData[j] is left as a hole. This sparse array is written verbatim to IMPORTED_SPREADSHEET.data via Onyx.set. Note the for (let colIndex = 0; colIndex < numColumns; colIndex++) loop right below builds columns densely for 0…numColumns-1, so columns gets a role entry for index j while data has none — the two fall out of sync.

3. On the mapping screen, pressing Import runs importTransactions, which rebuilds rows from the column‑major data:

App/src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx

Lines 197 to 203 in 557846e

	for (let rowIndex = 0; rowIndex < (columns.at(0)?.length ?? 0); rowIndex++) {
	const row: string[] = [];
	for (const column of columns) {
	row.push(column.at(rowIndex) ?? '');
	}
	rows.push(row);
	}

The loop bound columns.at(0)?.length ?? 0 reads the length of column 0, which is a present, non‑empty array (the header's first cell exists), so the loop runs. The inner for (const column of columns) then iterates every index — and for…of yields undefined for a hole (unlike map/forEach, which skip them). When column is the hole at index j, column.at(rowIndex) throws TypeError: Cannot read properties of undefined (reading 'at'). The ?? '' guards the result of .at(), never the receiver.

Because importTransactions is async and is passed directly as onPress={importFunction} to the Import Button, the throw becomes an unhandled promise rejection — exactly the reported auto.browser.global_handlers.onunhandledrejection with useSingleExecution / BaseGenericPressable frames on the stack.

Sibling contrast (why the bug is rare and why adjacent cases stay silent):

• If the hole were at column index 0, columns.at(0)?.length ?? 0 short‑circuits to 0, the loop body never runs, and Import silently produces no rows — no crash. Only a hole at index > 0 (with column 0 present) triggers it.
• The other import consumers dereference each column defensively: ImportedMembersPage uses spreadsheet?.data?.at(col)?.some(...) and ImportedMerchantRulesPage uses spreadsheet?.data.at(col)?.at(row)…. Their ?.at() turns a hole column into undefined → '' instead of throwing. The company‑cards page is the only consumer that iterates all columns via for…of and calls a bare column.at(...) with no receiver guard.
• The mapping UI itself hides the evidence: ImportSpreadsheetColumns renders columns with spreadsheetColumns.map(...), which skips the hole, so the user sees N-1 columns, maps them, and only hits the mismatch at Import time.

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

We should fix this at the single producer of the column‑major data — setSpreadsheetData — so IMPORTED_SPREADSHEET.data is always a dense, rectangular string[][] and no consumer can inherit a hole. Replace the hole‑preserving firstRow.map(...) with an index‑based dense construction at ImportSpreadsheet.ts:40:

-    const transposedData: string[][] = firstRow.map((_, colIndex) => data.map((row) => String(row.at(colIndex) ?? '')));
+    const transposedData: string[][] = Array.from({length: numColumns}, (_, colIndex) => data.map((row) => String(row.at(colIndex) ?? '')));

Array.from({length: numColumns}, …) visits every index 0…numColumns-1 densely, so a hole in firstRow no longer produces a missing column — index j becomes a real string[] of ''s instead of an undefined slot.

This is safe because:

• numColumns is firstRow.length (ImportSpreadsheet.ts:37), and a sparse array's length already counts holes, so the produced column count and indices are identical to the old firstRow.map((_, colIndex) => …) — for any dense (normal) input the output is byte‑for‑byte the same.
• The inner data.map((row) => String(row.at(colIndex) ?? '')) is untouched; it already normalizes ragged/short rows and missing cells to '', so every produced column is a defined string[], honoring the declared string[][] type.
• It restores the invariant that data.length === Object.keys(columns).length that the columnNames loop at ImportSpreadsheet.ts:42-45 assumes, so the previously‑hidden blank column now renders and is mappable.
• Every import flow (company cards, tags, categories, per diem, members) reads this same data; fixing the sole producer resolves the reported crash and removes the latent hole risk from the other flows that dereference the mapped column without a ?. guard — without editing any consumer.

Note: a narrower guard at the crash site (column?.at(rowIndex) ?? '') would only silence the throw on this one screen while leaving data sparse — the blank column would still be dropped from the mapping UI, data.length would still disagree with the columns role map, and the same malformed value would still reach the tags/categories/per‑diem consumers that read the mapped column via .map without a ?.. Enforcing the rectangular contract at the boundary keeps all consumers correct.

What alternative solutions did you explore? (Optional)

• Guard the receiver at the crash site — row.push(column?.at(rowIndex) ?? '') in CompanyCardsImportedPage. Rejected: it patches one leaf of several consumers, leaves IMPORTED_SPREADSHEET.data sparse, and keeps the blank column hidden in the mapping UI while data/columns stay out of sync.
• Pass defval: '' to sheet_to_json — fills missing cells inside existing columns, but relies on SheetJS‑version‑specific behavior and is immediately re‑sparsified by the subsequent row.map(...) in ImportSpreadsheet.tsx; it fixes the symptom at the library edge rather than enforcing the string[][] contract at our own transpose, which is where the type is promised.

[Ollyws]

Melvin's proposal fixes the symptoms rather than the root cause, @yusufdeveloper2903's solution LGTM.

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @Julesssss, see https://stackoverflow.com/c/expensify/questions/7972 for more details.