Apply the upload limit only where something is uploaded #212

New Issue

Closed

opened 2026-09-02 07:58:50 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-02 07:58:50 +00:00

Owner

Closes the doc/code contradiction flagged on #197.

FEATURES has always said attach-from-Files works "however large", because a blob the account already holds is attached by reference and nothing is sent. The code checked every file against maxSizeUpload regardless. The two disagreed, and the code was the one that was wrong.

Why

maxSizeUpload is what the server will accept for a single upload (RFC 8620). It bears on a file that is about to be uploaded and on nothing else.

Applying it to a by-reference attachment refused a 60 MB message the server was already storing, on the grounds that it could not have been uploaded — which it was not being. Forwarding a large message as an attachment (#197) hit exactly that: the feature's whole point is that it costs no upload, and the limit denied it anyway.

A file from somebody else's account is fetched and re-uploaded into this one, because a message can only carry blobs from the account sending it. That upload is real, and the limit is real for it, so it still applies there.

Testing

5 new store tests: a same-account blob of any size attaches with no error, no blobId loss and no request made at all; a cross-account blob over the limit is refused; one under it proceeds to upload; and a mixed drop judges each file by whether it will actually be uploaded.

The "no request made" assertion is the one that matters — fetch is stubbed to throw, so an attempted upload fails the test rather than passing quietly.

Suite green: web 865 across 88 files, server 122, typecheck clean.

Merged 2026-09-02 as coffey-labs/ihasmail@8962065782

_{Rebuilt from: git history, session transcript.}

Closes the doc/code contradiction flagged on #197. FEATURES has always said attach-from-Files works **"however large"**, because a blob the account already holds is attached by reference and nothing is sent. The code checked *every* file against `maxSizeUpload` regardless. The two disagreed, and the code was the one that was wrong. ## Why `maxSizeUpload` is what the server will accept for **a single upload** (RFC 8620). It bears on a file that is about to be uploaded and on nothing else. Applying it to a by-reference attachment refused a 60 MB message the server was *already storing*, on the grounds that it could not have been uploaded — which it was not being. Forwarding a large message as an attachment (#197) hit exactly that: the feature's whole point is that it costs no upload, and the limit denied it anyway. A file from somebody else's account **is** fetched and re-uploaded into this one, because a message can only carry blobs from the account sending it. That upload is real, and the limit is real for it, so it still applies there. ## Testing 5 new store tests: a same-account blob of any size attaches with no error, no `blobId` loss and **no request made at all**; a cross-account blob over the limit is refused; one under it proceeds to upload; and a mixed drop judges each file by whether it will actually be uploaded. The "no request made" assertion is the one that matters — `fetch` is stubbed to throw, so an attempted upload fails the test rather than passing quietly. Suite green: web 865 across 88 files, server 122, typecheck clean. **Merged** 2026-09-02 as coffey-labs/ihasmail@8962065782ba <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#212