attachment list returns an empty array for most threads that search --attachment matches (1.3.0 and 1.4.0)

[lh]

What happens

hey attachment list <topic_id> returns

{"ok": true, "data": [], "summary": "0 attachments in thread <id>"}

for threads that demonstrably carry attachments.

Why I'm confident the attachments are really there

Two independent server-side signals disagree with the CLI:

1. hey search --attachment pdfs returns these very threads, so HEY's own index has them flagged as carrying a PDF.
2. hey thread read <topic_id> renders the message body ending in a paperclip marker followed by the real filename.

Rate

Of the 10 most recent threads returned by hey search --attachment pdfs --date last_90_days, only 3 returned anything from attachment list. The other 7 all show a paperclip marker and filename in the rendered body.

One of the missed threads carries six separate attachment markers and discovers none of them.

Versions

Reproduced identically on:

• 1.3.0 (Homebrew cask, basecamp/tap/hey)
• 1.4.0 (official hey_1.4.0_darwin_arm64.tar.gz from the release page, SHA-256 verified against checksums.txt)

macOS 15, arm64.

This is not #285

That bug fired ~200 sequential GETs and reported Attachment discovery stopped after 100 pages of thread messages. Here -vv shows exactly two requests and a clean empty return, on both passing and failing threads. The walker isn't spinning; it fetches, finds nothing, and returns.

Retrieval itself is healthy. On threads where discovery does find the file, hey attachment save writes a byte-exact file (verified by size and by opening the PDF).

Not a caching artifact

1.4.0 enables the SDK ETag response cache, and verbose output showed both threads served from cache (304). I moved ~/.cache/hey-cli aside and re-ran cold: identical results.

Shape unknown

It affects both forwarded mail and mail sent directly to me, so it isn't simply a forwarding problem. I could not find a discriminator: inline-image count doesn't predict it (there are failures with zero inline images and successes with one). Senders span several unrelated providers, including Exchange/Outlook relays and ordinary transactional senders.

I've kept thread IDs and filenames out of this report since they're from a personal mailbox, but I'm very happy to run any diagnostic that would help narrow it down, or to send sanitised verbose output.

[lh]

Follow-up with a much larger sample, and one correction to my own numbers above.

Corrected rate

I swept 97 candidate threads via hey search --attachment across pdfs, documents, any, spreadsheets and images, --date 2026, pages 1-3, on 1.4.0.

70 of them carry a real paperclip marker in the rendered body:

attachment list returned	Threads
nothing	39 (56%)
some but not all	6 (9%)
everything	25 (36%)

So 45 of 70 attachment-bearing threads are affected, not the 7-of-10 my first sample suggested.

Correction worth making, in fairness

A further 13 threads matched --attachment but show no paperclip at all in the body. These look like inline signature images, and attachment list returning nothing for them is arguably correct behaviour. I've excluded them from the figures above. Anyone reproducing this should do the same, or the bug looks worse than it is.

The finding that I think actually matters: it's per-attachment

Six threads returned some of their attachments and not others. In one, the body lists five files and attachment list returned two.

That rules out the tidy explanations. It isn't "this thread is broken", or "this message is broken", or "this sender is broken" — within a single message, some attachments come back and others don't. Whatever the discovery walker is doing, it's dropping individual attachments rather than failing wholesale.

Hypotheses I tested and ruled out

Hypothesis	Verdict
Only forwarded mail	No. Fails on directly-sent mail too.
Specific sender or provider	No. The same sender domains appear in both the working and failing groups.
File type	No. PDF 68% missed (n=72), docx 52% (n=31), xlsx 77% (n=13), doc 50% (n=10), ics 44% (n=9). Every common type appears on both sides.
Position within the thread	No. Missed: 35 on the latest message vs 25 on earlier ones. Found: 25 vs 12. Same shape.
Thread length	No. Single-message threads miss 28 of 47; multi-message miss 11 of 23.
Inline images in the body	No. Failures with zero inline images, successes with several.
Flakiness / race	No. Five consecutive runs against three failing threads returned 0 every time. Deterministic.

The one signal that survives

Discovery rate falls as the message body grows:

Body size (rendered)	Discovered
under 200 chars	7/12 (58%)
200-1,000	7/11 (64%)
1,000-3,000	12/36 (33%)
over 3,000	11/38 (29%)

Missed messages average 5,666 chars against 2,550 for found ones, and carry more images, links and table markup.

It's a trend rather than a rule — short bodies fail and long ones succeed — so it can't predict an individual case. My guess, and it is only a guess since I can't see the MIME from the CLI, is that this is really tracking MIME structure: an attachment nested inside a multipart/related or multipart/alternative tree rather than sitting as a top-level part. Heavy HTML mail is just where that nesting tends to occur. Someone with access to the raw MIME could confirm or kill that quickly.

Happy to supply specific thread IDs privately if that would help — I've kept them out of this thread since they're from a personal mailbox, but they're all in my own account and I can send them to support or paste them wherever is useful.

[lh]

Root cause found, and it answers the discriminator question I could not settle above. Posted in full on #351 with the patch, since that issue is older and has the second reporter: #351

Short version: htmlutil.findAttachments never descends into the embedded text/html Trix attachment that HEY wraps an inbound email's markup in, while findImages and ToMarkdown both do. So the split is inbound versus composed-in-HEY, not forwarding, sender or inline-image count. That also explains the "some but not all" row in my sweep: a thread carrying one of each lists one of two.

Happy for this to be closed as a duplicate of #351.