Skip to content

feat: [M3-7257] - Invalidate VPC-related queries after deleting a linode#9814

Merged
coliu-akamai merged 6 commits intolinode:developfrom
coliu-akamai:feat-m3-7257
Oct 19, 2023
Merged

feat: [M3-7257] - Invalidate VPC-related queries after deleting a linode#9814
coliu-akamai merged 6 commits intolinode:developfrom
coliu-akamai:feat-m3-7257

Conversation

@coliu-akamai
Copy link
Contributor

@coliu-akamai coliu-akamai commented Oct 18, 2023

Description 📝

  • After deleting a linode, because we didn't invalidate any VPC related queries, the VPC pages would have incorrect information unless we refreshed the page. This change invalidates VPC related queries when deleting a linode so that the vpc pages are up to date.

Changes 🔄

List any change relevant to the reviewer.

  • Added utility function to get all vpcs a linode is assigned to with, based on its configs
  • Invalidate vpc-related queries for vpcs a linode is assigned to
  • Added some extra spacing underneath the 'Reboot linode banner' on a VPC details page -- seems like there was spacing missing, added more to make it align more with the mockups
  • updated VPC todo comments to be consistent - //@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,

  • Have a linode and at least two vpc's created (each with at least one subnet)

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:

  • Linode assigned to one vpc one subnet
  • Linode assigned to one vpc (multiple subnets within that VPC)
  • Linode assigned to two+ VPCs

Tests

  • yarn test LinodesLanding/utils.test.ts

As an Author I have considered 🤔

Check all that apply

  • 👀 Doing a self review
  • ❔ Our contribution guidelines
  • 🤏 Splitting feature into small PRs
  • ➕ Adding a changeset
  • 🧪 Providing/Improving test coverage
  • 🔐 Removing all sensitive information from the code and PR description
  • 🚩 Using a feature flag to protect the release
  • 👣 Providing comprehensive reproduction steps
  • 📑 Providing or updating our documentation
  • 🕛 Scheduling a pair reviewing session
  • 📱 Providing mobile support
  • ♿ Providing accessibility support

@coliu-akamai coliu-akamai added the VPC Relating to VPC project label Oct 18, 2023
@coliu-akamai coliu-akamai self-assigned this Oct 18, 2023
Copy link
Contributor Author

@coliu-akamai coliu-akamai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +30 to +37
const flags = useFlags();
const { data: account } = useAccount();

const enableVPCActions = isFeatureEnabled(
'VPCs',
Boolean(flags.vpc),
account?.capabilities ?? []
);
Copy link
Contributor Author

@coliu-akamai coliu-akamai Oct 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding this check to determine when to fire the useAllLinodeConfigsQuery (line 49) -- feature flagging the query, basically

linodeId !== undefined && open
);

const { data: configs } = useAllLinodeConfigsQuery(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is reasonable 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you are correct! This is good!

{numLinodes > 0 && (
<DismissibleBanner
preferenceKey={`reboot-linodes-warning-banner-${vpc.id}`}
sx={{ marginBottom: theme.spacing(2) }}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see PR description for reasoning behind this additional margin

@coliu-akamai coliu-akamai marked this pull request as ready for review October 18, 2023 18:02
@coliu-akamai coliu-akamai requested a review from a team as a code owner October 18, 2023 18:02
@coliu-akamai coliu-akamai requested review from bnussman-akamai, dwiley-akamai, hana-akamai and tyler-akamai and removed request for a team October 18, 2023 18:02
Copy link
Contributor

@abailly-akamai abailly-akamai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Query invalidated and approach is solid to me ✅

const vpcIds = getVPCsFromLinodeConfigs([config]);
expect(vpcIds).toEqual([2, 3]);
});
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

linodeId !== undefined && open
);

const { data: configs } = useAllLinodeConfigsQuery(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is reasonable 👍

linodeId !== undefined && open
);

const { data: configs } = useAllLinodeConfigsQuery(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you are correct! This is good!

Comment on lines +63 to +76
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,
]);
});
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could go either way with it, but I like this more targeted invalidation approach

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@dwiley-akamai dwiley-akamai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VPC pages are correctly updated after Linode deletion for each of the test cases ✅
Code review ✅

Comment on lines +63 to +76
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,
]);
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could go either way with it, but I like this more targeted invalidation approach

@coliu-akamai coliu-akamai added Approved Multiple approvals and ready to merge! and removed Ready for Review labels Oct 19, 2023
@coliu-akamai
Copy link
Contributor Author

Merging as cypress test failures are not due to vpc issues/not from this PR!

@coliu-akamai coliu-akamai merged commit 54b5f00 into linode:develop Oct 19, 2023
@coliu-akamai coliu-akamai deleted the feat-m3-7257 branch November 6, 2023 19:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Approved Multiple approvals and ready to merge! VPC Relating to VPC project

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants