mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-11 08:47:33 +00:00
Claude
3dbf247108
A cashuB token pasted into a DM didn't render the redeem card — the user saw the raw base64 + a useless "Show more" button. Root cause was in ExpandableTextCutOffCalculator. The user's token was ~480 chars with no whitespace anywhere. The calculator saw `min == content.length > TOO_FAR_SEARCH_THE_OTHER_WAY (450)`, fell into the backward-search branch, found no space or newline in the first SHORT_TEXT_LENGTH (350) chars either, and returned 350 — slicing the token mid-base64. The truncated string still started with "cashuB", so the parser matched a CashuSegment, but CashuPreview's base64 decode failed on the corrupt body and it fell back to rendering the raw text. Fix: when there's no whitespace boundary anywhere in the first SHORT_TEXT_LENGTH chars during backward search, return content.length — the entire content is one indivisible atom (cashuA/cashuB, base64 data: URI, lnbc, single huge URL), so cutting it can only corrupt the segment. The pre-existing testImage was locking in the same bug for a ~11k-char data: URI (truncated to 350 → broken image segment); updated it to assert image.length and added two new regression tests around the user's exact cashuB token and a "preamble + long token" case where the cut should land cleanly at the boundary before the token. Also added a CashuTokenParserTest covering the parser side (which was already correct) so any future change that breaks cashuB detection is caught.