Export a guard for `VoidActionError` at every status

Fermée
  • Quelque chose ne va pas ?
#714 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@karthickeyan-dev y travaille déjà.

Depuis le 4/11/2026.

  • #715 par @karthickeyan-dev — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
78/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
backend-api-design, documentation

Piste de recherche

Start by locating the exports for isCallSiteActionError() in void/pages-client and the thrown-error section of docs/guide/pages-routing/actions-and-forms.md. Check how categorizeActionError() classifies statuses and how the existing guard is tested. Done means a new guard recognizes VoidActionError across statuses, the call-site guard uses it, and both guards are documented.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

Follow-up to #680, as #691 suggested ("that can be a separate change"). Since 1.6.0, a 4xx action error's message is the server's text, thanks for that. #680's other ask is still open: a guard that recognises a VoidActionError at every status.

The actions guide says 401, 403 and 5xx are thrown, and to "handle them with your framework's error boundary". But the only guard Void exports, isCallSiteActionError(), is false for exactly those statuses. So an error boundary can't tell an action error from any other error without reproducing Void's internals.

Reproduction
// pages/notes.server.ts
import { HTTPException } from 'hono/http-exception';
import { defineHandler } from 'void';

export const action = defineHandler(async (c) => {
  const status = Number(c.req.query('status'));
  throw new HTTPException(status as 403, { message: 'You can vote once your account is a day old' });
});

// pages/notes.tsx
import { isCallSiteActionError } from 'void/pages-client';

try {
  await action(`/notes?status=${status}`, { data: {} });
} catch (error) {
  isCallSiteActionError(error); // false for 401, 403 and 5xx
}
Status action() error.name isCallSiteActionError()
409 returns VoidActionError true
401 throws VoidActionError false
403 throws VoidActionError false
500 throws VoidActionError false
Why it matters
  • The boundary the docs point to has no guard. It has to tell an action error from a render bug to show a 403's message, send a 401 to login, or show a generic message for a 500.
  • Every app copies the guard's internals. instanceof VoidActionError isn't reliable when the class is bundled more than once, which is why isCallSiteActionError() checks error.name. Apps do the same by hand, relying on a class name the docs never mention.
  • Neither exported helper is documented. isCallSiteActionError() and categorizeActionError() are exported from void/pages-client but don't appear in the guide or the API reference.
Proposal

  1. Export isVoidActionError() next to isCallSiteActionError(), true for every status:

    export function isVoidActionError(error: unknown): error is VoidActionError {
  return (
    typeof error === 'object' &&
    error !== null &&
    'name' in error &&
    error.name === 'VoidActionError' &&
    'status' in error &&
    typeof error.status === 'number'
  );
}

export function isCallSiteActionError(error: unknown): error is VoidActionError {
  return isVoidActionError(error) && categorizeActionError(error.status) === 'callSite';
}

  2. Document both guards in the actions guide, next to the paragraph on thrown errors.

Prior art
  • React Router: isRouteErrorResponse(error) recognises a thrown response in an error boundary, at any status.
  • SvelteKit: isHttpError(error, status?) recognises an error() at any status, or a given one.
Workaround
// By name: instanceof fails across bundled copies.
export function isActionError(error: unknown): error is VoidActionError {
  return error instanceof Error && error.name === 'VoidActionError';
}
Environment
  • void 1.6.1
  • @void/react 1.6.1
Langage dominant
TypeScript
Étoiles
627
Forks
66
Merge moyen
14 h 17 min
PR mergées (30 j)
200

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

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de voidzero-dev/void

Toutes les issues de voidzero-dev/void

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.