hey attachments finds 0 attachments on threads that definitely have one (multipart/mixed with sibling multipart/alternative)

[lh]

Environment

• hey version: 0.1.1 (commit c0d3441894f1e04eb6d5bf2c0d71dea15754931c, built 2026-08-20)
• Go: go1.26.6
• Installed via brew install --cask basecamp/tap/hey
• macOS (arm64)

Summary

hey attachments <thread-id> reports 0 attachments on threads that have a genuine attachment, confirmed by inspecting the raw RFC822 source of the message via the Hey web app. This reproduces consistently across three independent real threads in my mailbox, all sharing a similar MIME shape.

Reproduction

The affected messages share this MIME structure (from Content-Type headers in the raw source):

multipart/mixed
 ├── multipart/alternative
 │    ├── text/plain
 │    └── text/html
 └── application/pdf  (Content-Disposition: attachment; filename="...")

All were relayed through an Exchange/Outlook-based sender (X-MS-Has-Attach: yes present in the header, ARC-sealed).

Running:

hey attachments <thread-id> --json

returns:

{
  "ok": true,
  "data": null,
  "summary": "0 attachments in thread <thread-id>",
  "notice": "Attachment discovery stopped after 100 pages of thread messages"
}

for a thread that contains exactly one message. The "100 pages of thread messages" wording is surprising on its own for a single-message thread.

What --verbose shows

Running with -vvv / --verbose, the command issues roughly 200 sequential HTTP GET requests, every one logged as status=200, before giving up:

time=... level=DEBUG msg="http request" method=GET
time=... level=DEBUG msg="http response" status=200
... (repeats ~100 times) ...

So this isn't an auth failure or a 4xx/5xx from the server — every request the client makes succeeds, but the discovery logic never surfaces the attachment. This looks like a pagination bug on the client side (a cursor that never advances, or pagination running against the wrong resource) rather than a server-side data problem.

Expected behavior

hey attachments <thread-id> should list the PDF attachment present on the message, as it does (per the docs) for other threads.

Actual behavior

Always 0 attachments, on every thread I've tested with this MIME shape, despite ~200 successful HTTP requests being made in the process.

Additional notes

• hey threads <thread-id> --json correctly returns the message body (text/plain part), so the client can see and parse this message fine — it's specifically the attachment-discovery path that fails.
• Happy to run additional diagnostics (increased verbosity, --account variations, etc.) if that's useful — I don't want to paste any real thread IDs or message content here since this mailbox carries clinical correspondence, but I'm glad to test against a specific request.

[robzolkos]

Closing as fixed — with an invitation to reopen if your threads disagree. The tell was in your own report: "stopped after 100 pages of thread messages" on a single-message thread. Your build (v0.1.1, built Aug 20) paged the thread's entry index by number against an opaque-cursor endpoint, re-fetching the first page ~100 times and giving up before ever reading the message — so the PDF was never seen, whatever its MIME shape. That walker was replaced on Aug 21 by a bounded loader that follows the real cursor. Could you hey upgrade and rerun hey attachments (now hey attachment list) on one of your three threads? If it still reports zero, reopen with the thread ID — at that point it would be a genuine parsing gap in the Exchange-shaped MIME and exactly the repro we'd need. Thanks for including the raw MIME structure; it ruled out half the hypotheses up front.