fix(datagrid): restore table tabs using the live page size

[datlechin]

Problem

After quitting and reopening the app, a restored table tab loaded only 500 rows even when the page size setting was 1000. The restored tab ignored the current setting. Freshly opened tabs were correct.

Root cause

A table tab persists its full SQL with the row limit baked into the query string (e.g. SELECT * FROM users LIMIT 500 OFFSET 0). On restore, that string was executed verbatim. For the common page-1, no-sort case the first-load path returned early without rebuilding the query, so the stale limit ran. A latent second issue: QueryTab.init(from:) seeded pagination from the static 1_000 constant instead of the live setting, so the in-memory page size could also drift once the user's setting was not 1000.

Fix

A restored table tab now regenerates its query from current structured state and the live page size. The persisted limit is never executed.

• QueryTab.init(from:defaultPageSize:) seeds pagination from the live page size; TabPersistenceCoordinator.restoreFromDisk passes AppSettingsManager.shared.dataGrid.defaultPageSize in.
• prepareTableTabFirstLoad rebuilds the table query on the fast path instead of returning early. This path only runs for not-yet-loaded tabs (already-loaded tabs are excluded by canAutoLoadTableTab), so freshly opened tabs are untouched. The slow path already rebuilt and now uses the correctly seeded page size.

This also fixes state files written by older builds, since the query is rebuilt from live state regardless of what was persisted. Per-tab page sizes reset to the current global setting on relaunch, matching how DataGrip, Postico, and TablePlus treat a relaunch as a fresh fetch.

Tests

• restoredTableTabUsesLivePageSize reproduces the reported bug: a restored tab whose persisted query carries LIMIT 500 loads with LIMIT 1000 when the setting is 1000.
• paginationSeedsFromLivePageSize covers the restore seeding.
• noneBehaviorRegeneratesQueryOnFastPath asserts the fast path regenerates the query.
• Updated every QueryTab(from:) call site for the new initializer signature.

Docs

No docs change. Bug fix with no UI or setting change.

[chatgpt-codex-connector]

💡 Codex Review

TablePro/TablePro/Views/Main/Extensions/MainContentCoordinator+TableFirstLoad.swift

Lines 39 to 40 in fc6e28f

	if restoreApplied || sortApplied || !tabManager.tabs[index].columnLayout.hiddenColumns.isEmpty {
	filterCoordinator.rebuildTableQuery(at: index)

Rebuild after consuming unmatched restored sort

When a restored tab has pendingRestoredSort but the saved column no longer exists (or metadata returns no matching column) and restoredPage is nil, firstLoadNeedsSchemaColumns takes the slow path, applyPendingRestoredViewState clears the pending state but returns false, and this condition skips rebuildTableQuery. In that scenario the first auto-load can still execute the restored SQL string, including the stale persisted LIMIT this change is trying to avoid; rebuild after consuming restored state even when no sort/page was applied.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".