You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(files): attribute a size rejection to the cap that actually bound it
Every PayloadSizeLimitError was reported as the entry exceeding its per-document
render allowance, quoting the 50 MiB headroom. That is wrong when the shared
budget was the smaller cap, and wrong for extensions that carry no headroom at
all — a video rejected because the budget ran out was told it exceeded a
per-document render limit.
The entry is now blamed only when its own allowance was the smaller of the two
caps, and the message quotes the allowance that applied rather than the
constant. The mapper also returns its outcome instead of mutating closure state,
which is what the aggregate and per-entry branches now read.
// Naming the entry that blew its own allowance, and quoting the allowance that
195
+
// actually applied: an aggregate message here would tell the user to select
196
+
// fewer files when the selection was fine.
181
197
returnNextResponse.json(
182
198
{
183
-
error: `"${overLimitFileName}" is too large to include in a zip. A single document may render up to ${formatFileSize(RENDERED_DOCUMENT_HEADROOM_BYTES)}; download it on its own instead.`,
199
+
error: `"${overLimitEntry.name}" is too large to include in a zip. Entries are capped at ${formatFileSize(overLimitEntry.allowance)}; download it on its own instead.`,
0 commit comments