fix(browse): guard Delete Row against not-yet-loaded record (RUM: undefined[0] TypeError)

[dawsontoth]

Summary

Fixes an unhandled TypeError: Cannot read properties of undefined (reading '0') surfaced in Datadog RUM on the table browse view (/$organizationId/$clusterId/databases/$databaseName/$tableName/), current deploy (commit 2ccba97c).

Root cause

The Delete Row button in EditTableRowModal reads the primary-key value with data[0]?.[primaryKey]. But data is undefined while the record fetch is in flight — the parent passes data={searchByIdData?.data} (see DatabaseTableView.tsx:616-618), and the footer (containing Delete Row) renders regardless of whether data has loaded. The ?. only guarded the [primaryKey] access, not the [0] — so clicking Delete before the record resolves does undefined[0] and throws.

The prop type declared data as a non-optional array, which hid the mismatch, even though the rest of the component already treats it as optional (data?.map(...), {data ? … : <Loading/>}).

Fix

• Make the prop type honest: data?: …[] (documents the loading state).
• Guard the read: data?.[0]?.[primaryKey].
• Add a regression test that renders with data={undefined} and clicks Delete Row, asserting it neither throws nor calls onDeleteRecord. (Fails the vitest run — exit 1 — without the fix.)

Datadog RUM findings

• Error: TypeError: Cannot read properties of undefined (reading '0') — handling: unhandled
• View: /$organizationId/$clusterId/databases/$databaseName/$tableName/
• Frequency: 2 events / 1 session / 1 user over the last 7d, all on commit 2ccba97c
• Frame: onClick @ index-*.js (the Delete Row handler), confirmed against the deployed bundle

Verification

tsc -b, oxlint, dprint clean; full suite green (1771 passed). The race (click Delete in the window before the record fetch resolves) isn't practically reproducible in the browser preview, so the unit test — which reproduces the exact data=undefined state — is the verification.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request makes the data prop optional in EditTableRowModal to handle cases where the record fetch is still in flight. It adds optional chaining (data?.[0]?.[primaryKey]) to prevent an unhandled exception when clicking the "Delete Row" button before data has loaded, and includes a corresponding unit test to verify this behavior. There are no review comments to address.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	51.88%	5559 / 10714
🔵	Statements	52.43%	5948 / 11344
🔵	Functions	44.38%	1376 / 3100
🔵	Branches	44.89%	3736 / 8322

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/features/instance/databases/modals/EditTableRowModal.tsx	60%	71.05%	50%	60%	61, 68-69, 81-138, 154-171

Generated in workflow #1572 for commit 43d4bcb by the Vitest Coverage Report Action

[cb1kenobi]

I think I ran into this once. Nice fix!