Await invalidations after mutations

[david-crespo]

Would close #3083. Experimenting with this while investigating a CI e2e flake on the silo IP pools tab. Leaving as a draft because I need to make sure I like it and I don't know about these tests.

Basically there are things in the UI that should wait for the invalidation after a mutation to be done, but currently we don't await invalidateEndpoint calls anywhere. It's hard for users to have a real problem with this because they don't click fast enough to beat the async invalidation, but it affects tests, and it also means that there is some visual pop-in after a side-modal closes but before the invalidation comes back.

🤖 description of invalidation race in e2e test

After unlinking ip-pool-1, the confirm modal closes before the invalidated queries finish refetching.

The test then opens ip-pool-2’s action menu. One of those late refetches updates the data used to build the row actions, replacing the action column and unmounting the open menu. Playwright either:

• finds “Clear default,” but it detaches while being clicked, or
• completes the click, but the confirmation dialog never opens.

The unlink itself succeeds; the failure is the UI becoming unstable during the unawaited refetch. Awaiting invalidation keeps the mutation—and therefore the modal—pending until those refetches settle.

We could manually await invalidations in all onSuccess callbacks (and make all success callbacks async) but the approach in this PR is neater and harder to mess up. When we do it manually, there's nothing forcing us to put the invalidations first. By defining them in this structured way, the useApiMutation helper ensures the invalidations always run first and it runs them in parallel instead of sequentially.

New invalidation API

useApiMutation(api.foo, {
  invalidateEndpoints: ['fooList', 'fooView'],
  onSuccess() {
    // runs after refetches finish
  },
})

UX considerations

Even when there isn't a bug actively caused by not awaiting, it still makes the UI jump around unnecessarily. One thing worth considering is whether we should find a way to do a kind of temporary glowy flash on new rows when they appear in the table. That would be kind of nice, especially now that the modal closing and the pop-in are simultaneous.

Before

It's subtle, but you can see that after creating a floating IP, the side modal closes and then the new floating IP pops into the list.

2026-08-27-await-invalidation-before.mp4

After

After successful creation, the side modal closes and the new floating IP appears at the same time.

2026-08-27-await-invalidation-after.mp4

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
console	Ready	Preview	Aug 27, 2026 9:57pm