-
Notifications
You must be signed in to change notification settings - Fork 16.6k
fix(sqllab): Skip progress bar on no data #37652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
fix(sqllab): Skip progress bar on no data #37652
Conversation
Code Review Agent Run #e4189cActionable Suggestions - 0Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
| }; | ||
| if ( | ||
| newQueries[id].state === QueryState.Success && | ||
| newQueries[id].runAsync === false && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: The condition that checks for synchronous queries uses a strict comparison runAsync === false, which will not match cases where runAsync is undefined or null even though those are effectively non-async runs, so such queries can incorrectly remain in the "success" state with no results and still show the confusing UI that this change intends to fix. Relaxing the check to treat any falsy runAsync as synchronous will make the logic robust against missing or optional runAsync values from the backend. [possible bug]
Severity Level: Major ⚠️
- ⚠️ Query status UI shows success with no results.
- ⚠️ Progress bar and no-data state may overlap.
- ⚠️ Backend omission of runAsync causes visual bug.| newQueries[id].runAsync === false && | |
| !newQueries[id].runAsync && |
Steps of Reproduction ✅
1. Cause REFRESH_QUERIES to run (superset-frontend/src/SqlLab/reducers/sqlLab.ts, handler
for [actions.REFRESH_QUERIES] around the PR diff lines 749-776).
2. Provide an alteredQueries entry for an existing query id where the server's
changedQuery object does not include runAsync (i.e., runAsync is undefined or omitted).
3. Reducer builds newQueries[id] and evaluates the added conditional at ~lines 762-768.
The strict comparison newQueries[id].runAsync === false fails when runAsync is undefined,
so the branch that sets state = QueryState.Fetching is skipped.
4. The query remains in QueryState.Success with no results populated, reproducing the UI
confusion (progress bar/no-data overlap) this PR aims to fix. This is observable in SQL
Lab query rows and the results pane after a refresh from the backend that omits runAsync.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** superset-frontend/src/SqlLab/reducers/sqlLab.ts
**Line:** 764:764
**Comment:**
*Possible Bug: The condition that checks for synchronous queries uses a strict comparison `runAsync === false`, which will not match cases where `runAsync` is `undefined` or `null` even though those are effectively non-async runs, so such queries can incorrectly remain in the "success" state with no results and still show the confusing UI that this change intends to fix. Relaxing the check to treat any falsy `runAsync` as synchronous will make the logic robust against missing or optional `runAsync` values from the backend.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.| } | ||
| if ( | ||
| shallowEqual( | ||
| omit(newQueries[id], ['extra']), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: In the refresh-queries handler, the equality optimization dereferences state.queries[id].extra without checking if the query already exists in state, but this block runs even when !state.queries.hasOwnProperty(id) is true, so for new query IDs state.queries[id] is undefined and accessing .extra will throw at runtime when refreshQueries is called with a previously unseen ID. [null pointer]
Severity Level: Critical 🚨
- ❌ Reducer throws during REFRESH_QUERIES processing.
- ❌ SQL Lab query list UI can fail to update.
- ⚠️ Polling/updates drop for affected query ids.| omit(newQueries[id], ['extra']), | |
| state.queries[id] && |
Steps of Reproduction ✅
1. In the running app, trigger the REFRESH_QUERIES reducer path by dispatching the
actions.REFRESH_QUERIES action. The reducer handler is in
superset-frontend/src/SqlLab/reducers/sqlLab.ts inside the [actions.REFRESH_QUERIES]()
block (the handler begins in the PR diff around lines 749-776).
2. Include an alteredQueries payload that contains a new query id not present in the
current Redux state. Example payload: { alteredQueries: { "newId": { state: "success", /*
other fields */ } } }. This causes the forEach branch guarded by the check at the top of
the loop (the clause that starts with "!state.queries.hasOwnProperty(id)" in the same
handler) to execute for that id.
3. Execution reaches the equality-optimization block starting at the if ( shallowEqual(...
) && isEqual(... ) ) { ... } portion (the block shown in the diff at ~lines 770-775).
Because state.queries["newId"] is undefined, the expression state.queries[id].extra is
evaluated and raises a TypeError (cannot read property 'extra' of undefined).
4. Observe a runtime exception thrown from the reducer path in the browser console and a
broken UI update for SQL Lab queries. The failure occurs deterministically when
REFRESH_QUERIES contains query IDs not already present in state. (If the reviewer
considers this a non-issue: the code's earlier condition explicitly allows this branch for
new ids by design, so the missing guard is a real bug.)Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** superset-frontend/src/SqlLab/reducers/sqlLab.ts
**Line:** 771:771
**Comment:**
*Null Pointer: In the refresh-queries handler, the equality optimization dereferences `state.queries[id].extra` without checking if the query already exists in state, but this block runs even when `!state.queries.hasOwnProperty(id)` is true, so for new query IDs `state.queries[id]` is `undefined` and accessing `.extra` will throw at runtime when `refreshQueries` is called with a previously unseen ID.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
SUMMARY
There is an issue where the query progress bar and the "no data" state are displayed together, which can cause confusion. This occurs because, in sync mode, when a query is executed, the batch query/updated_since is triggered at the moment the query results are being parsed. As a result, the query state changes to "success" before the results are actually populated.
This commit modifies the process so that, just like in async mode, the state changes to "fetching" during this period. This prevents misunderstanding by displaying the correct status until the results are available.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:
After:
TESTING INSTRUCTIONS
specs are added
ADDITIONAL INFORMATION