fix(browse): refresh the table once an import's job completes

[dawsontoth]

Problem

A CSV import into the open table follows its job, but when the job succeeds and the dialog closes, the grid, its count and the database overview still show the rows from before the import until a manual Refresh (found by Dawson hand-testing the release candidate on stage).

Every Browse read has a 60s staleTime, and the import only refetched describe_all and navigated to the table already on screen, which fetches nothing. #1880 did not cause this. #1471 (125b6e57d) did: when it moved the import modal from DatabaseTableView into DatabaseActionModals, it dropped the table view's refreshTable() call.

Solution

useImportDataMutation refreshes from its own onSettled, so the refresh still happens after the modal unmounts (React Query skips a mutate call's own callbacks then). It invalidates [entityId, database, table] (page, filtered search, exact count, describe_table), the open record's search_by_id key, and describe_all.

The refresh is not awaited, so the import settles and the modal closes at the job's verdict, as before. onImported still waits for describe_all before navigating, or resolveDatabasesRedirect would send a table the import just created back to the overview. It now joins the mutation's refetch (awaitDatabaseMapRefresh, cancelRefetch: false) instead of starting a second one.

Every outcome refetches, failures included, because any of them can have written rows. The strongest case is a submission with no verdict (no response, or a 502/503/504): its toast says "Outcome unknown, check whether it took effect", and a grid left on cached rows would invite a retry that duplicates every record without an id. When the instance is really down, the re-reads add their own error toasts; that is the accepted cost.

Every outcome that can write, and why a failed re-read is safe

• A job that completes with skipped rows (successfully loaded 3 of 5 records, or a JSON insert's (N skipped)).
• A job that ended in ERROR: csv_url_load inserts in 2 MB chunks (harper dataLayer/bulkLoad.ts, insertChunk), so the chunks before the failing one stay written.
• A wait that timed out on a load still running.
• A load refused after the import's own create_table made the table.
• A submission with no verdict, for example a central-manager 504 on a long insert that Harper went on to apply.

invalidateQueries swallows fetch failures unless throwOnError is set (query-core 5.104.1 src/queryClient.ts:520-521), so a failed re-read is not an unhandled rejection. A throw from the refresh itself is caught, so it cannot turn a completed import into a failure.

No other job follower has this gap. waitForJob is used only by the import, and followRestartJob's callers await it through mutateAsync and then invalidate.

The databases DESIGN.md records where the refresh lives and why.

Verification

• New tests in importData.test.tsx and DatabaseActionModals.test.tsx use the real query-key builders and Browse's own query options. Against stage's sources, 10 of the 21 tests in those two files fail.
• Each of 11 single mutants on the final code fails at least one test.
• Gates (Node 24.21.0) all pass: npx vitest run --maxWorkers=4 (524 files), npx tsc -b, npx oxlint --format stylish . and npx dprint check. Under load from other sessions, JobsTab's 200-row test (from feat(status): list Harper jobs on a Jobs tab, and follow a CSV import's job in a toast #1880, untouched here) times out at 5s, even run alone.
• Not checked in a browser, because an import against a stage cluster writes to it.

Test cases, mutants and review history

Tests:

• a completed job with skipped rows refetches the page, describe_table and describe_all after the modal unmounted. It marks the filtered search, exact count and open record stale, and leaves another table alone.
• each failure above refetches too, plus polls that stopped answering;
• re-reads that fail end in error state without an unhandled rejection;
• the mutation settles while describe_all is in flight, and the map wait joins that refetch;
• a throwing refresh leaves the import successful;
• onImported navigates only once describe_all is back.

The 11 mutants:

• no refresh;
• success only;
• no refresh without a response;
• each of the three invalidations dropped;
• no guard;
• cancelling the in-flight refetch;
• awaiting the refresh;
• onImported not waiting;
• throwOnError: true, where vitest fails the run with an unhandled AxiosError: Network Error.

Cross-model review, five rounds (codex, gemini, Cursor, Harper domain adjudication). The closing full round ran on e59d02f37, and the delta round on 3d8f58efc converged.

Changed from review:

• the refresh is not awaited;
• a refusal after create_table refetches;
• a no-verdict failure refetches;
• search_by_id is invalidated;
• the DESIGN note was added.

Declined:

• .ts import extensions: none of the 1,369 relative imports in src has one, and tsconfig doesn't allow them.
• the async settleQuietly and join-order concerns: progress.onSuccess is a synchronous toast, and onImported runs after onSettled.
• two test comments: both state a reason.

Pre-existing, worth a separate issue:

• waitForJob giving up on a running load reports a plain failure, not "Outcome unknown" (getJob.ts:67-68, :89-90).
• a failed describe_all refetch still lets onImported navigate against the old map.

Related PRs: #1864 overlaps (already in stage; same DatabaseActionModals files, but the Add Records path, not the import refresh), 4 others independent

🤖 Generated with Claude Code

_{Review-Coverage: authored=claude; ran=cursor-composer,gemini,codex,cursor-muse; adjudicated=domain; declined=cursor-grok,cursor-kimi,muse; rounds=5; full=2 @ 3d8f58e}

_{Review-Attention: read ~3m (decisions: refetch-after-any-outcome, describe-all-refetch-all-on-failure, join-relies-on-callback-order, do-less-alternative) @ 3d8f58e}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	77.59%	13391 / 17258
🔵	Statements	77.54%	14215 / 18332
🔵	Functions	72.44%	3523 / 4863
🔵	Branches	72.53%	10514 / 14495

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/features/instance/databases/components/DatabaseActionModals.tsx	80.85%	45.61%	53.84%	80.85%	103-104, 108-109, 118-147
src/integrations/api/instance/database/importData.ts	78.94%	34.78%	92.3%	78.78%	41-44, 74-75, 106

Generated in workflow #2336 for commit 3d8f58e by the Vitest Coverage Report Action

[gemini-code-assist]

Code Review

This pull request refactors the database import flow to trigger Browse refreshes directly from the useImportDataMutation's onSettled callback rather than the modal, ensuring that data is refreshed even if the modal unmounts. It introduces logic to refetch queries when the instance responds, or mark them stale when there is no verdict (e.g., network errors or 502/503/504 statuses). Additionally, comprehensive tests and design documentation have been added. Feedback on the changes suggests adding .catch() handlers to the fire-and-forget queryClient.invalidateQueries calls in refreshImportedTable to prevent unhandled promise rejections.