Export a guard for `VoidActionError` at every status

Offen
  • Stimmt etwas nicht?
#714 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@karthickeyan-dev arbeitet bereits daran.

Seit 04.11.2026.

  • #715 von @karthickeyan-dev — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
78/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
backend-api-design, documentation

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
Vorherrschende Sprache
TypeScript
Sterne
627
Forks
66
Ø Merge
13 Std. 57 Min.
Gemergte PRs (30 T.)
194

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/void

Alle Issues in voidzero-dev/void

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.