`VoidActionError.message` ignores the server's message, though the docs show it to users

Abierto
  • ¿Algo no está bien?
#680 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
react, typescript
Área
documentation, frontend

Línea de trabajo

Start in pages/action-result.ts, where the VoidActionError constructor builds message and currently reads body only for a 429 usage limit. Then read the action() section of docs/guide/pages-routing/actions-and-forms.md, which shows result.error.message in a toast. Done when a 4xx with a text body sets message to that body, 5xx and empty bodies keep the status line, and the docs describe message accurately. The optional isVoidActionError() export is a separate decision to confirm with maintainers.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

When an action fails, VoidActionError.message is a status line such as Action failed with 404 Not Found. A 429's usage-limit message is the only exception. The handler's own message, for example from HTTPException, ends up only in error.body.

The action() guide shows the message to users:

if (!result.ok) {
  showToast(result.error.message);
}

Followed as written, that toast says "Action failed with 404 Not Found" instead of what the action said.

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 404, { message: 'That note was deleted.' });
});

// pages/notes.tsx
const result = await action(`/notes?status=${status}`, { data: {} });
// For 403 and 500, action() throws, so read the caught error instead.

The server answers with the message as text/plain. On the client:

Status action() error.message error.body isCallSiteActionError()
404 returns Action failed with 404 Not Found That note was deleted. true
409 returns Action failed with 409 Conflict That note was deleted. true
422 returns Action failed with 422 Unprocessable Entity That note was deleted. true
403 throws Action failed with 403 Forbidden That note was deleted. false
500 throws Action failed with 500 Internal Server Error That note was deleted. false

The message is built in VoidActionError's constructor (pages/action-result.ts), which reads body only for a 429's usage limit.

Why it matters
  • The documented pattern shows a status line. An app that follows the guide shows users text written for developers.
  • Every app writes the same helper. To show the action's message, each app checks that body is a non-empty string and falls back otherwise, and has to know that Void stores a text body there.
  • Thrown errors have no guard. 401, 403 and 5xx reach the error boundary, where the only exported guard, isCallSiteActionError(), is false for them. Apps check error.name === 'VoidActionError' by hand, as the guard itself does, because instanceof isn't reliable when the class is bundled more than once.
Proposal
  1. Use the server's text for 4xx. When the status is 4xx and body is a non-empty string, set message to it, as the constructor already does for a 429's limit message. Keep the status line for 5xx, where the text may not be meant for users, and when there's no body. status and statusText still carry the status.
  2. Export isVoidActionError(), true for every status, so error boundaries can recognise action errors.
  3. At minimum, fix the docs. Say what message holds, and change the action() example to read error.body with a fallback.
Prior art
  • Better Auth, which Void bundles: a failed call's error.message is the server's message.
  • SvelteKit: error(404, 'That note was deleted.') reaches the page as page.error.message.
Workaround
// By name: instanceof fails across bundled copies.
function isActionError(error: unknown): error is VoidActionError {
  return error instanceof Error && error.name === 'VoidActionError';
}

function getErrorMessage(error: unknown): string {
  if (isActionError(error) && error.status < 500 && typeof error.body === 'string' && error.body) {
    return error.body;
  }
  return 'Something went wrong, please try again';
}
Environment
  • void 1.5.0
  • @void/react 1.5.0
Lenguaje dominante
TypeScript
Estrellas
627
Forks
66
Merge medio
14 h 38 min
PR fusionados (30 d)
179

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de voidzero-dev/void

Todos los issues de voidzero-dev/void

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.