Publish endpoint returns 500 with masked Server Components error on long post

[aaronstevenwhite]

500 Internal Server Error when publishing long post with code blocks

Description

Publishing a draft via the editor fails with a 500 from the publish endpoint. The error reaches the Server Components layer and is masked in production, so I cannot see the underlying cause from the client side.

Steps to reproduce

1. Create a new post in the editor.
2. Paste a long markdown body (~600 lines, ~30KB) containing several fenced code blocks (YAML, JSON, and a Nickel-like config), inline code, headings, and external link cards.
3. Click Publish.

Expected behavior

The post is published, or the server returns a 4xx with a human-readable explanation of what's wrong with the input (e.g. "post too long", "unsupported syntax at line N").

Actual behavior

The publish request returns a 500 and the editor surfaces an unhandled Server Components render error. No information about the failure is exposed to the client.

Console output

POST https://leaflet.pub/[post_id_redacted]/publish 500 (Internal Server Error)

Uncaught (in promise) Error: An error occurred in the Server Components render.
The specific message is omitted in production builds to avoid leaking sensitive
details. A digest property is included on this error instance which may provide
additional details about the nature of the error.

• Post ID: [redacted]
• Deployment ID (from bundle URLs): dpl_5BNcdz9iG6iTwUegzGyQVDex3K4y
• The error object carries a digest property that should let you locate the corresponding server-side stack trace in your logs.

Environment

• Browser: Chrome on macOS
• Reproducible: Yes (retrying the publish does not resolve the error).

Notes

• The post contains nothing unusual beyond its length and the number of fenced code blocks; no embedded media uploads, no custom HTML, no unusual characters. IT does use a substantial number of footnotes however.
• A preview of the draft renders well.
• A 500 with a hidden message means there is no path for an end user to diagnose or work around the failure. Even if the post genuinely violates some server-side constraint (size, syntax, etc.), it would help a lot if the publish endpoint returned that as a structured 4xx so the editor could surface it.

What would help

1. A real error message (or at least a documented error code) returned to the client when publish fails for content reasons.
2. If this turns out to be a size limit or a parser bug, a brief note in the docs about the supported limits.
3. Investigation against the post ID and deployment ID above to locate the server-side stack trace.

[bschlagel]

Hi @aaronstevenwhite thanks for the detailed report here! Looks like you were eventually able to get this post published — do you recall if it was any particular change e.g. removing certain blocks or shortening overall that got it to work, or just repeated tries?

Agree we need better error handling here. Best guess is a length / record size issue, plan is to move to storing content as blobs, but not totally sure, @jaredpereira may have other ideas

(FYI editing above to redact the post id b/c it contains the edit link; others cant update the published post, but could edit the draft with that so removing just to be safe)