-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
Fix for polling queries #7559
Fix for polling queries #7559
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7559 +/- ##
==========================================
- Coverage 65.2% 65.18% -0.03%
==========================================
Files 433 433
Lines 21433 21428 -5
Branches 2360 2358 -2
==========================================
- Hits 13975 13967 -8
- Misses 7338 7341 +3
Partials 120 120
Continue to review full report at Codecov.
|
Is there no way to make the |
@mistercrunch in theory it should be. I fixed an eager commit that created a race condition, but even after deploying the fix @vylc reported it still happening. I was hoping it was a a bad node that didn't pick up the change, but I checked all hosts and they were indeed running the fix, which is why I made this workaround. |
Tried to look into the code as to where that commit may be happening and couldn't find it... Maybe something in there like the Would this help/work? The idea is that |
@mistercrunch I think that would work. I still need to fix the polling though: currently it keeps polling when sync queries are present. Do you think we should keep this PR as is, since it's safer, or should I modify it to remove the line that says: (q.state === 'success' && q.asyncRun && q.resultsKey === null) |
I think like we should remove that line that was there before, feels like duct tape to me. I opened the PR #7575 on my side. |
@mistercrunch @graceguo-supercat I reverted the changes that made the unnecessary polling. |
thanks @betodealmeida Look at this line, where we set query status we set |
@graceguo-supercat yeah, that might be the problem. @mistercrunch moved that line (setting the status to success) to before the commit, ensuring that it has |
wow thanks!! the issue is finally got fixed! |
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.
LGTM
Just an idea...
CATEGORY
Choose one
SUMMARY
#7446 (review) changed the polling mechanism to keep polling when a query succeeds but doesn't have a
resultsKey
, to work around a race condition in SQL Lab. @graceguo-supercat pointed out that synchronous queries do not haveresultsKey
, and when they run the frontend keeps polling the backend unnecessarily.This PR changes the logic so that the frontend keeps polling only for async queries that succeeded but don't have
resultsKeys
set.TEST PLAN
Without this PR, this happens:
resultsKey
.With this PR, the browser stops polling once the async query finishes.
ADDITIONAL INFORMATION
REVIEWERS
@graceguo-supercat