fix(datagrid): resolve default sort before dispatching the first table query#1605
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5907dfaf46
ℹ️ 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".
|
|
||
| let task = Task { | ||
| if let entry = await fetch() { | ||
| self.entries[key] = entry |
There was a problem hiding this comment.
Prevent stale schema loads from repopulating the cache
When refreshTables() or teardown calls schemaColumns.removeAll(), this store cancels in-flight loads and clears entries, but any metadata fetch that does not promptly observe cancellation can still resume and write its old result here. That means a schema refresh can be followed by the previous fetchColumns result reappearing under the same key, so later default-sort or hidden-column logic can use stale column/PK metadata until another invalidation; the generation check only controls loads cleanup and does not guard the cache write.
Useful? React with 👍 / 👎.
…and extract the schema-wait predicate
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7899dd23e5
ℹ️ 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".
| return | ||
| } | ||
|
|
||
| let sql = tab.content.query |
There was a problem hiding this comment.
Preserve default-sort resolution for manual table runs
This direct dispatch path now skips the default-sort preparation that was removed just above, so any first table execution that does not come from lazyLoadCurrentTabIfNeeded()—for example pressing the editor Run/Cmd-Enter action on a restored or deferred table tab—uses the original SELECT ... LIMIT ... without resolving the app/plugin default sort or rebuilding the table query. The new prepareTableTabFirstLoad only runs from the lazy-load task, but runQuery() still routes table tabs here directly, so the first query can be unsorted despite default sorting being enabled.
Useful? React with 👍 / 👎.
Fixes #1603
Problem
With Default row sort set to Primary key, the first table opened after launch loaded unsorted. Closing and reopening it, or opening any other table, sorted correctly. The 0.49.1 fix (#1604) did not cover the first open.
Root cause
The first-load gate consumed its one-shot flag before the async schema fetch finished. On a cold cache, while fetchColumns was on the network, two other dispatch paths (the lazy-load view task and the new-window setup path) saw the flag already set, skipped the gate, and executed the unsorted query first. A warm cache resolved synchronously, which is why every open after the first worked.
Fix
Refactor of the first-load flow instead of another patch on the flag:
Behavior: composite PK sorts by all key columns in key order; tables and views without a PK load unsorted with no indicator and no error; a user header sort always wins over the default.
Tests
Notes for review