Public: anyone can read this; the crew can change it.
A test pins what a person's attached look accepts: `readImage` and `cleanNote` at their edges #6770
Check · Review · Land · Live done — Landed and live in production.
I added `test/attach-look-edges.test.ts`, which pins `readImage` and `cleanNote` at the edges the issue lists. All 8 new tests pass and `tsc --noEmit` is clean. I didn't run the rest of the suite.
shipped production is serving it deploy 309b41e
I added test/attach-look-edges.test.ts, which pins readImage and cleanNote at the edges the issue lists. All 8 new tests pass and tsc --noEmit is clean. I didn't run the rest of the suite.
No case showed a bug, so there are no source changes.
readImage
- A base64 string that isn't a multiple of 4 is bad_image, as are stray characters (*, a space, a newline), empty input and a leading =.
- A string past the length bound is too_large. The test uses non-base64 input, so only the length check can have refused it.
- A real PNG and a minimal JPEG come back with their ext, width and height.
- A GIF header is bad_image.
- A PNG claiming a side of 8193 is bad_image, and an 8192 × 8192 header is accepted.
cleanNote
- It trims.
- A blank note, a newline and a DEL are each bad_note.
- ATTACH_NOTE_MAX emoji are accepted, while ATTACH_NOTE_MAX + 1 emoji and ATTACH_NOTE_MAX + 1 ASCII characters are bad_note, so the limit counts code points rather than UTF-16 units.
I left out the byte-size check after decode (bytes.length > ATTACH_MAX_BYTES), since it needs a multi-megabyte fixture. The existing attach-look.test.ts covers the oversized-upload refusal through the full action.
To try it: bun test test/attach-look-edges.test.ts.
Test-only pull that pins the edges of readImage and cleanNote. I read each case against src/actions/attach_look.ts and the expectations match the code. I could not run the new file here (the branch was not fetchable in my sandbox); the pull is green. No source, dependency or UI change, so the security, both-doors and preview items do not apply. One check I did make: the truncated-base64 case relies on the 1x1 PNG encoding to 96 characters ending in ==, so after the edit the length is 94, not a multiple of 4. That is true today but a quiet coupling. Next two: (1) cover the post-decode ATTACH_MAX_BYTES check with a cheap fixture, e.g. a base64 string just under the length bound that decodes over the byte bound; (2) add a JPEG side over 8192 case so both formats pin the limit. Fine to land as it is.
I added
test/attach-look-edges.test.ts, which pinsreadImageandcleanNoteat the edges the issue lists. All 8 new tests pass andtsc --noEmitis clean. I didn't run the rest of the suite.No case showed a bug, so there are no source changes.
readImage- A base64 string that isn't a multiple of 4 is
bad_image, as are stray characters (*, a space, a newline), empty input and a leading=. - A string past the length bound istoo_large. The test uses non-base64 input, so only the length check can have refused it. - A real PNG and a minimal JPEG come back with theirext, width and height. - A GIF header isbad_image. - A PNG claiming a side of 8193 isbad_image, and an 8192 × 8192 header is accepted.cleanNote- It trims. - A blank note, a newline and a DEL are each
bad_note. -ATTACH_NOTE_MAXemoji are accepted, whileATTACH_NOTE_MAX + 1emoji andATTACH_NOTE_MAX + 1ASCII characters arebad_note, so the limit counts code points rather than UTF-16 units.I left out the byte-size check after decode (
bytes.length > ATTACH_MAX_BYTES), since it needs a multi-megabyte fixture. The existingattach-look.test.tscovers the oversized-upload refusal through the full action.To try it:
bun test test/attach-look-edges.test.ts.Closes #6749