Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Bug]: Guest messages near the 4,000-char limit fail with 400 "The request was not valid." because multipart turns \n into \r\n

Abierto Apto para principiantes
  • ¿Algo no está bien?
#26,534 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@juliusmarminge ya está trabajando en esto.

Desde el 28/10/2026.

  • #26541 de @Aareksio — cerrado sin fusionar
  • #26542 de @juliusmarminge — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
api, backend

Línea de trabajo

Lee apps/server/src/guest/http.ts:192 y la ruta circundante readSubmission/decodeSubmit hasta el badRequest genérico en la línea 219. Reproduce publicando un mensaje de invitado multipart cuya longitud tipada esté por debajo de 4.000 pero cuya longitud en el wire crezca de \n a \r\n, luego normaliza los finales de línea antes de isMaxLength y devuelve una razón too_long específica. Hecho significa que dicho mensaje se acepta, se almacena con \n, y un mensaje realmente demasiado grande recibe un error distinto.

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

Descripción

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

Guest share links (T3 Connect "share with link")

Steps to reproduce
  1. Share a thread with a link, open it as a guest, enter a name.
  2. In the guest composer, type or paste a multi-line message that is under 4,000 characters, but where the length plus the number of line breaks is over 4,000 (for example a long email draft with paragraphs).
  3. Send it.
Expected behavior

The message is accepted. The textarea's maxLength={GUEST_MESSAGE_MAX_LENGTH} let it through, so the server should accept it too. If the message really is too long, the guest should see a specific error.

Actual behavior

POST /api/guest/messages returns 400 and the guest sees "The request was not valid." Retrying fails the same way (8 attempts in my logs).

Cause: GuestComposer sends the text through FormData. Multipart/form-data serialization turns every \n in string entries into \r\n (per the HTML spec; Chrome and undici both do this). The server then decodes parts.text with TrimmedString.check(isMaxLength(GUEST_MESSAGE_MAX_LENGTH)) (apps/server/src/guest/http.ts:192). That check counts each line break as 2 characters, so the decode fails and the route falls through to the generic badRequest (http.ts:219).

Repro of the inflation in Node 26:

const t = "a\n".repeat(2000).slice(0, 3999);
const fd = new FormData(); fd.append("text", t);
const body = await new Response(fd).text();
// client length 3999 -> wire length 5998

Two smaller issues on the same path:

  • Accepted multi-line guest messages are stored with \r\n.
  • A schema failure (for example the text being too long) comes back as reason: "invalid" / "The request was not valid." instead of a specific reason like too_long, so the guest can't tell what to fix.
Impact

Guests can't send longer, formatted messages, and the error gives them no hint about why. In practice the feature looks broken.

Version or commit

0.1.4-nightly.20261028.3824 (desktop, Windows + WSL server)

Environment

Owner: T3 Code Nightly desktop on Windows, server in WSL2. Guest: browser, through the *.t3coderelay.com relay.

Logs or stack traces

Server trace, all on share 1FLJ…:

16:11:29 POST /api/guest/redeem   204
16:20:08 POST /api/guest/messages 400
... (x8, last at 16:22:06)

GuestShareService.check succeeds on each of these requests, so the session is valid. The 400 comes from readSubmission/decodeSubmit.

Why it has to be the text length:

  • The shareId was the same in the failing requests and the successful ones.
  • Attachments work: one of the later, accepted messages had a PNG attached.
  • "The request was not valid." comes only from badRequest, so the multipart parse succeeded. The only check left that can fail is isMaxLength on text.

At 15:25 the guest split the same content into two messages (770 and 3285 characters as typed), and both were accepted (204). Both are stored with \r\n line endings (2 and 19 of them), which confirms the normalization happens on the way to the server. The textarea's maxLength also cuts pasted text silently at 4000, so a long paste is the easiest way to hit this: 4000 characters plus N newlines.

Workaround

Shorten the message so that its length plus the number of line breaks is ≤ 4,000, or put the long text in an attached .txt file.

Suggested fix: on the server, normalize \r\n → \n before the length check (or send the text as JSON next to the files). Also return a specific too_long reason, and optionally show a character counter in the guest composer.

🤖 Opus 5.5 on behalf of the user

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
2 h 54 min
PR fusionados (30 d)
350

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.