`hey attachments` re-walks the same page ~100 times; returns 0, 100x duplicates, or a 500

[rsalesas]

hey attachments walks the same page ~100 times, so discovery returns wrong results and the command is effectively unusable. Every invocation ends with:

"notice": "Attachment discovery stopped after 100 pages of thread messages"

including on threads with a single message. -vv on a one-message thread shows 201 HTTP requests.

The page appears to be re-fetched rather than advanced, and the visible outcome depends on where the attachment sits. On threads that hey search --attachment pdfs returns, I get three different wrong answers:

1. Attachment reported 100 times — one copy per re-fetched page, all byte-identical:

$ hey attachments 2065075618 --json
100 entries, 1 distinct  (id "2194754328:1", application/pdf, 119857 bytes)
"summary": "100 attachments in thread 2065075618"

2. Zero attachments, though search says the thread has a PDF:

$ hey search --attachment pdfs --from mail.anthropic.com --date last_30_days --json
2094196841  Your receipt from Anthropic, PBC #...

$ hey attachments 2094196841 --json      # thread has exactly 1 message
"summary": "0 attachments in thread 2094196841"

3. API error: 500 Internal Server Error — threads 1914117743 and 2008389069 in the same sample.

The zero case is deterministic, not a race: three consecutive runs all returned 0, and --account all / an explicit --account <id> make no difference.

That thread really does have a PDF. --attachment pdfs discriminates correctly — as a control, two senders whose mail is known to carry no PDF return nothing at all:

$ hey search --attachment pdfs --from notify.cloudflare.com --date last_30_days   # 0 threads
$ hey search --attachment pdfs --from email.apple.com      --date last_30_days   # 0 threads

save inherits the failure, because it resolves its id through the same discovery:

$ hey attachments save 2225707884:1     # message id of the thread above
attachment "2225707884:1" not found     # same for :2, :3

The download path itself is fine. When discovery does surface an id, save fetches it correctly:

$ hey attachments save 2194754328:1 --output ./probe.pdf
Attachment saved  (119857 bytes; PDF document, version 1.7, 1 pages)

So the defect looks confined to the pagination walk in discovery, not to fetching.

Why it matters: there is currently no way to get an attachment out of the CLI unless discovery happens to land on it, and no way to distinguish a genuinely attachment-free thread from a failed walk, since both report 0. For archiving receipts and invoices off Paper Trail that is the whole use case.

Likely the same walk as #181 (hey box --all returning one page twice) and #109 — the duplicate-page symptom there and the 100x duplicate here look like the same cursor failing to advance.

Two smaller things noticed alongside:

• The help examples (hey attachments save 67890:1) read as though the id is a thread id. Real ids are <message_id>:<index>, and passing a thread id returns resource not found, which sends you looking in the wrong place. The index is 1-based; :0 is rejected as malformed.
• An invalid --attachment value surfaces as a raw API 500 rather than a client-side usage error: hey search --attachment pdf (singular) 500s, while hey search filters lists the valid value as pdfs. Cheap to validate against that list before the request.

Against 0.1.1 (c0d3441), macOS, release install.

[rsalesas]

Correction and some extra evidence on the zero case.

Thread 2094196841 does not have one PDF attachment — it has two, and hey attachments reports 0 for it. My original write-up understated the miss.

Opening the same thread in the web app and reading the rendered DOM shows both attachments present as ordinary links, with distinct sizes:

<invoice>.pdf    34410 bytes
<receipt>.pdf    35259 bytes

Both are plain Active Storage blob links of the usual shape (identifiers elided):

https://app.hey.com/rails/active_storage/blobs/redirect/<signed-blob-id>/<filename>.pdf

I fetched both successfully from within the authenticated page, so the attachments are reachable and intact — the thread is simply invisible to hey attachments, which walks its 100 pages and returns nothing. This rules out the benign reading that these are inline or otherwise non-attachment parts: they are real, downloadable attachments that discovery never sees.

Also worth noting for triage: the 0 and the 100x duplicate are the same thread shape — a single message carrying attachments. One thread yields the attachment 100 times, the other yields it zero times, which fits a cursor that neither advances nor reliably lands on the message rather than a per-thread data difference.

hey upgrade is a no-op — 0.1.1 (c0d3441) is the current release, so this reproduces on latest.