fix(sqllab): async queries no longer stuck at Running forever - #42896
Draft
sadpandajoe wants to merge 1 commit into
Draft
fix(sqllab): async queries no longer stuck at Running forever#42896sadpandajoe wants to merge 1 commit into
sadpandajoe wants to merge 1 commit into
Conversation
REFRESH_QUERIES's stale-poll guard blocked any incoming Success update whenever the locally stored state was Running, Fetching, or Success. Fetching/Success make sense to guard (a late poll shouldn't clobber a state that's already at or past Success), but Running is strictly before Success, so an incoming Success there is genuine new information, not staleness. For async-mode queries (allow_run_async databases), this poller (QueryAutoRefresh, via REFRESH_QUERIES) is the only path that ever updates their state - runQuery only dispatches querySuccess directly for the synchronous case. Once such a query was observed Running, it could never reach Success: every subsequent poll re-applied the same guard against the same stuck prevState. Drop Running from the blocked-state list so a genuine Running -> Success transition is no longer discarded.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #42896 +/- ##
=======================================
Coverage 66.38% 66.38%
=======================================
Files 2857 2857
Lines 161133 161133
Branches 37064 37064
=======================================
+ Hits 106967 106968 +1
+ Misses 52147 52146 -1
Partials 2019 2019
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
Contributor
|
🎪 Showtime deployed environment on GHA for 2f88576 • Environment: http://54.244.83.173:8080 (admin/admin) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix(sqllab): async queries no longer stuck at Running forever
SUMMARY
REFRESH_QUERIES's stale-poll guard in the SQL Lab reducer discarded anyincoming
Successupdate whenever the locally stored query state wasRunning,Fetching, orSuccess. GuardingFetching/Successmakessense (a late-arriving poll response shouldn't clobber a state that's
already at or past
Success), butRunningis strictly beforeSuccessin the query lifecycle, so an incomingSuccesswhile localstate is
Runningis genuine new information, not a stale duplicate.For async-mode queries (databases with
allow_run_asyncenabled), theperiodic background poller (
QueryAutoRefreshdispatchingREFRESH_QUERIES) is the only mechanism that ever updates their stateclient-side —
runQueryonly dispatchesquerySuccessdirectly for thesynchronous case. Once such a query was observed in
Running, it couldnever reach
Success: every subsequent poll re-applied the same guardagainst the same locally-stuck
prevState, so the query appearedpermanently "running" in the UI (e.g. the SQL Lab Query History pane)
even though it had long since finished on the backend.
This drops
Runningfrom the blocked-state list so a genuineRunning -> Successtransition is no longer discarded, while keeping theFetching/Successguard intact for its original purpose.BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A. Behavior-only SQL Lab reducer fix (async query status polling); no
visual/layout change.
TESTING INSTRUCTIONS
allow_run_asyncenabled.the UI (e.g. Query History) once the backend job completes, instead of
remaining stuck at "Running" indefinitely.
Automated/local checks run:
npx jest src/SqlLab/reducers/sqlLab.test.ts(new + existing tests, 39/39 pass)npx jest src/SqlLab/(full directory, 45 suites / 423 passed, 1 pre-existing skip)npx oxlint --config oxlint.json --quieton changed files (clean)npx oxfmt --checkon changed files (clean)ADDITIONAL INFORMATION
SQLLAB_BACKEND_PERSISTENCEis not required;reproduction requires a database with
allow_run_asyncenabled