Prototype awaited mutation invalidations

[david-crespo]

Would close #3083

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

Experimenting with this while investigating a CI e2e flake on the silo IP pools tab. 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 run into the problem because they don't click fast enough to beat the async invalidation, but it affects tests.

🤖 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 this is neater and harder to mess up. When we do it manually, there's nothing requiring that we put the invalidations happen before the navigation or whatever is supposed to happen after. 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.

Leaving as a draft because I need to make sure I like it and I don't know about these tests.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
console	Ready	Preview	Aug 27, 2026 12:03am