React: `action()` and `router.visit()` never resolve when awaited in a transition
Les mainteneurs répondent en général sous 1 jour
@cpojer y travaille déjà.
Depuis le 30/10/2026.
Évaluation
Cette issue n'a pas encore été évaluée.
Description
React: action() and router.visit() never resolve when awaited in a transition
What happens
Awaiting action() or router.visit() inside a React transition never resolves: the transition's isPending stays true and code after the await never runs. It happens with startTransition(async () => …), a <form action={fn}> function and useActionState, which React all runs as transitions.
// pages/repro.server.ts
import { defineHandler, type InferProps } from 'void';
export type Props = InferProps<typeof loader>;
export const loader = defineHandler(async () => ({ loadedAt: Date.now() }));
export const actions = {
ping: defineHandler(async () => {}),
};
// pages/repro.tsx
import { action } from '@void/react';
import { useTransition } from 'react';
import type { Props } from './repro.server';
export default function Repro({ loadedAt }: Props) {
const [isPending, startTransition] = useTransition();
function save() {
startTransition(async () => {
await action('/repro?ping');
console.log('saved'); // never runs
});
}
return (
<button onClick={save} disabled={isPending}>
{isPending ? 'Saving…' : `Save (loaded at ${loadedAt})`}
</button>
);
}
Clicking Save leaves the button on "Saving…" for good. The same await action() called from a plain onClick, outside a transition, resolves.
Versions: seen with void 1.3.0, @void/react 1.3.0 and react 19.3.1. The code involved is unchanged in 1.4.0.
Why
It's a circular wait. Line numbers are from the built 1.4.0 packages:
action()callssubmitAction(), which awaitsrouter.visit()(void/dist/pages/client.mjs:1198).- The visit promise resolves in
finishNavigation, afterresource.commit(), so only once React has committed the new page (@void/react/dist/runtime/pages-client.mjs:265-277). - Void shows the new page with a
dispatchinside its ownstartTransition(pages-client.mjs:425). - React batches transitions that are pending at the same time: "If there are multiple ongoing Transitions, React currently batches them together" (
useTransitioncaveats). Void's update can't commit until the caller's transition ends.
So the caller's transition waits for action(), action() waits for the commit, and the commit waits for the caller's transition.
Void already avoids this for useForm. VisitOptions has an internal option for exactly this case (void/dist/pages/client.d.mts:44):
/** @internal Used by React Actions to avoid waiting for a commit blocked by the action itself. */
_resolveOnShell?: boolean;
useForm runs inside useActionState (@void/react/dist/index.mjs:288) and passes _resolveOnShell: true (index.mjs:304), so its visit resolves as soon as the page data arrives (pages-client.mjs:358). action() passes only { method, data } (void/dist/pages/client.mjs:1234), so it waits for the commit.
Why it matters
action() is how you call an action when useForm doesn't fit, such as a delete button outside a form. React 19's own ways to show a pending state (useTransition, useActionState, <form action>) are exactly the ones that hang. Apps have to track pending with useState and keep action() out of transitions, and nothing in the docs says so.
Proposal: resolve action() when the page data arrives
Pass _resolveOnShell: true in action(), as useForm does. The result (ok with pageData, or error) is complete by then, and the new page commits when the caller's transition ends. Both ways of calling an action would then behave the same.
Alternatives
- A public option on
action()androuter.visit(), e.g.{ resolveOn: 'data' }, keeping today's resolve-after-commit as the default for callers that need the new page on screen when theawaitreturns. - At least, document it:
action()androuter.visit()can't be awaited inside a transition,useActionStateor a<form action>function.
- Langage dominant
- TypeScript
- Étoiles
- 627
- Forks
- 66
- Merge moyen
- 14 h 56 min
- PR mergées (30 j)
- 170
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de voidzero-dev/void
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
voidzero-dev/void#677 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 3/5 1-2 jours Accessibilité débutants 52/100
voidzero-dev/void#680 ·
Les mainteneurs répondent en général sous 1 jour
-
`withValidator({ body })` rejects the multipart bodies that `useForm` and `action()` send for filesOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
voidzero-dev/void#679 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
voidzero-dev/void#676 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 18/100
voidzero-dev/void#667 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de voidzero-dev/void
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
oxidecomputer/skepsis#102 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
kunchenguid/gh-axi#247 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
lidge-jun/opencodex#8101 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
effort:S P3 refactor
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
nightscout/nocturne#3243 ·
Les mainteneurs répondent en général sous 1 jour