feat: [M3-7257] - Invalidate VPC-related queries after deleting a linode#9814
feat: [M3-7257] - Invalidate VPC-related queries after deleting a linode#9814coliu-akamai merged 6 commits intolinode:developfrom
Conversation
coliu-akamai
left a comment
There was a problem hiding this comment.
One thing I noticed when working on this PR is that when we navigate back to the VPC landing and detail pages, we see the old information for a brief moment before it gets updated. I've tried looking having the landing/detail pages be up to date as soon as we navigate to those pages, but wasn't having a lot of luck. Wondering if this is just how React Query works / is it bc of active/inactive queries or something?
| const flags = useFlags(); | ||
| const { data: account } = useAccount(); | ||
|
|
||
| const enableVPCActions = isFeatureEnabled( | ||
| 'VPCs', | ||
| Boolean(flags.vpc), | ||
| account?.capabilities ?? [] | ||
| ); |
There was a problem hiding this comment.
Adding this check to determine when to fire the useAllLinodeConfigsQuery (line 49) -- feature flagging the query, basically
| linodeId !== undefined && open | ||
| ); | ||
|
|
||
| const { data: configs } = useAllLinodeConfigsQuery( |
There was a problem hiding this comment.
The PR to include a VPC column in the LInodes Landing page table caused a bunch of 429s due to the useAllLinodeConfigsQuery being fired for every single linode. (see prs #9485 and #9625 for context + their respective tickets)
I think that would be less of an issue here bc we only fire this query when we are deleting the linode (and also only if the user has VPC capabilities), not for every single linode, but please lmk if I'm mistaken!
There was a problem hiding this comment.
I think this is reasonable 👍
There was a problem hiding this comment.
Yeah, you are correct! This is good!
| {numLinodes > 0 && ( | ||
| <DismissibleBanner | ||
| preferenceKey={`reboot-linodes-warning-banner-${vpc.id}`} | ||
| sx={{ marginBottom: theme.spacing(2) }} |
There was a problem hiding this comment.
see PR description for reasoning behind this additional margin
abailly-akamai
left a comment
There was a problem hiding this comment.
Query invalidated and approach is solid to me ✅
| const vpcIds = getVPCsFromLinodeConfigs([config]); | ||
| expect(vpcIds).toEqual([2, 3]); | ||
| }); | ||
| }); |
| linodeId !== undefined && open | ||
| ); | ||
|
|
||
| const { data: configs } = useAllLinodeConfigsQuery( |
There was a problem hiding this comment.
I think this is reasonable 👍
packages/manager/src/features/Linodes/LinodesLanding/DeleteLinodeDialog.tsx
Show resolved
Hide resolved
| linodeId !== undefined && open | ||
| ); | ||
|
|
||
| const { data: configs } = useAllLinodeConfigsQuery( |
There was a problem hiding this comment.
Yeah, you are correct! This is good!
| const vpcIds = getVPCsFromLinodeConfigs(configs ?? []); | ||
| if (vpcIds.length > 0) { | ||
| queryClient.invalidateQueries([vpcQueryKey, 'paginated']); | ||
| // invalidate data for specific vpcs this linode is assigned to | ||
| vpcIds.forEach((vpcId) => { | ||
| queryClient.invalidateQueries([vpcQueryKey, 'vpc', vpcId]); | ||
| queryClient.invalidateQueries([ | ||
| vpcQueryKey, | ||
| 'vpc', | ||
| vpcId, | ||
| subnetQueryKey, | ||
| ]); | ||
| }); | ||
| } |
There was a problem hiding this comment.
This logic looks good to me. Generally, I prefer to have invalidation logic inside of the useDeleteLinodeMutation's onSuccess in the packages/manager/src/queries/linodes/linodes.ts file but in situations like this, I think this is a fair approach.
The one flaw of this approach is that it is technically possible (but probably unlikely) for the Linode configs to not have loaded by the time we run this logic.
I know I told you that for invalidations, "it’s best to be as specific as possible", but I just looked at packages/manager/src/queries/linodes/events.ts and it looks like we handle volumes and firewalls there. Maybe we should just follow that pattern for now? The benefit of invalidating based on the event is that invalidation can happen across many instances of cloud manager that the user may have open.
There was a problem hiding this comment.
We could go either way with it, but I like this more targeted invalidation approach
There was a problem hiding this comment.
In that case will go with this more targeted approach for now. Maybe when we no longer need the feature flag/account capabilities check, we can return to this?
dwiley-akamai
left a comment
There was a problem hiding this comment.
VPC pages are correctly updated after Linode deletion for each of the test cases ✅
Code review ✅
| const vpcIds = getVPCsFromLinodeConfigs(configs ?? []); | ||
| if (vpcIds.length > 0) { | ||
| queryClient.invalidateQueries([vpcQueryKey, 'paginated']); | ||
| // invalidate data for specific vpcs this linode is assigned to | ||
| vpcIds.forEach((vpcId) => { | ||
| queryClient.invalidateQueries([vpcQueryKey, 'vpc', vpcId]); | ||
| queryClient.invalidateQueries([ | ||
| vpcQueryKey, | ||
| 'vpc', | ||
| vpcId, | ||
| subnetQueryKey, | ||
| ]); | ||
| }); | ||
| } |
There was a problem hiding this comment.
We could go either way with it, but I like this more targeted invalidation approach
… todo comments to be consistent
|
Merging as cypress test failures are not due to vpc issues/not from this PR! |
Description 📝
Changes 🔄
List any change relevant to the reviewer.
//@TODO VPC: ...todos...Preview 📷
Before:
https://github.com/linode/manager/assets/139280159/eb4fae00-dbf0-49af-b54f-bb3ec449e307
After:
https://github.com/linode/manager/assets/139280159/24012745-b602-4aef-abd6-abe724c85c3c
How to test 🧪
Prerequisites
(How to setup test environment)
Use the dev environment, with VPC tags,
Verification steps
(How to verify changes)
Verify that the VPC landing page and specific VPC detail pages are correctly updated after you delete a linode that is assigned to a VPC. Test the following cases:
Tests
yarn test LinodesLanding/utils.test.tsAs an Author I have considered 🤔
Check all that apply