Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
  • Is something wrong?
#26,534 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@juliusmarminge is already working on this.

Since Oct 28, 2026.

  • #26541 by @Aareksio — closed without merging
  • #26542 by @juliusmarminge — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
node.js, typescript
Domain
api, backend

Research direction

Read apps/server/src/guest/http.ts:192 and the surrounding readSubmission/decodeSubmit path down to the generic badRequest at line 219. Reproduce by posting a multipart guest message whose typed length is under 4,000 but whose wire length grows from \n to \r\n, then normalize line endings before isMaxLength and return a specific too_long reason. Done means such a message is accepted, stored with \n, and an actually oversized message gets a distinct error.

Written by the indexing model from the issue text.

Description

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

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
2h 54m
Merged PRs (30d)
350

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.