-
Notifications
You must be signed in to change notification settings - Fork 126
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
Remove query cancellation from StateManagers #3948
Conversation
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.
It doesn't appear like these cancelQueries
calls are adding any value to the dashboard. Out-of-the-box query cancellation works just fine without these explicit calls. Can you go ahead and remove the calls and related code?
However, for now can you keep the calls in ModelBody.svelte
and resource-invalidations.ts
? IIRC those are there as a ham-fisted way to cancel/invalidate outstanding queries.
@AdityaHegde and @djbarnwal would love to get your takes on this also before we go forward with any changes. @ericpgreen2 and I have been looking at query cancellation in the context of https://github.com/rilldata/rill-private-issues/issues/112, and think that we might be doing extra manual cancellations in places where tanstack should be able to do that automatically. I think that as a team, we need to audit all of those manual cancellation and understand why they are needed, and if they can be removed. @AdityaHegde, I've assigned this to you because I think you probably know the most about the intersection between runtime and client here. I think "done" on this would be code comments for any places we want to retain manual query cancellation. I don't mind making the changes in this PR if you just want to put those comments as review comments. |
I haven't personally worked a lot with query cancellation and relied on tanstack for it. I am up for removing manual cancellation if they don't have any performance implications. |
queryClient.cancelQueries({ | ||
predicate: (query) => isProfilingQuery(query, resource.meta.name.name), | ||
}); | ||
// queryClient.cancelQueries({ |
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.
We need these since there could be a race condition in request for profile sent and added to queue in backend vs the entity being deleted.
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.
Same applies to line 158 and line 99 in ModelBody.
@ericpgreen2 cleaning this up to get it over the line -- removed changes in ModelBody.svelte and resource-invalidations.ts, per you and @AdityaHegde's suggestions |
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.
Great. Looks like a good low-risk cleanup.
experiment with removing query cancellation
Here's what I see in a couple conditions
(1) state as of changes in this PR:
observeContextColumnWidth
reactive statement commented outResults:
firefox_DpIsohhvGJ.mp4
(2) Main before this PR, but without
observeContextColumnWidth
observeContextColumnWidth
reactive statement commented outResults:
https://github.com/rilldata/rill/assets/2380975/194cfdfc-769a-4fdb-9acb-ad7b5d115205