Follow-up to #279. The pagination walk there is genuinely fixed by #310 — duplicates are gone, a one-message thread now costs 3 requests instead of 201, and latency dropped from ~30s to ~0.5s. Thanks for the quick turnaround.
Two symptoms from that report did not travel with the cursor fix, and #279 was closed as completed, so filing them separately and more narrowly. My original write-up presented all three together, which probably obscured that they had different causes.
1. attachment list reports 0 for threads that do have attachments
Sweeping every thread that HEY's own search flags as carrying a PDF, over the last 30 days:
$ hey search --attachment pdfs --date last_30_days --all # 30 threads
$ hey attachment list <each>
correct: 13 wrongly reports 0: 13 API 500: 4
So 17 of 30 fail. The zero case is not search over-matching. Opening four of the zero threads in the web app and counting distinct active_storage/blobs links in the rendered DOM:
2084682588 -> 2 attachments in DOM, list says 0
2094353181 -> 2 attachments in DOM, list says 0
2102522008 -> 1 attachment in DOM, list says 0
2094196841 -> 2 attachments in DOM, list says 0
The search filter itself is trustworthy — as controls, two senders whose mail carries no PDF return no matches at all:
$ hey search --attachment pdfs --from notify.cloudflare.com --date last_30_days # 0
$ hey search --attachment pdfs --from email.apple.com --date last_30_days # 0
attachment save offers no way around it, since it resolves ids through the same listing:
$ hey attachment save <message-id>:1
attachment "<message-id>:1" not found
Full set of threads reporting 0 while search says they carry a PDF:
1851787710 2084682588 2087720185 2089427019 2091421345 2092613597 2094196841
2094353181 2094787227 2098233429 2102522008 2104333096 2108847621
There is no way to tell this apart from a genuinely attachment-free thread — both report 0.
2. API error: 500 Internal Server Error on some threads
Four threads in the same sweep fail outright rather than returning a wrong count:
1914117743 2008389069 2098168839 2104355561
Reproducible on every run. These also returned 500 on 0.1.1, so this predates the cursor change and is unrelated to it.
Both against 1.2.1 (58c83f1), macOS, release install.
Follow-up to #279. The pagination walk there is genuinely fixed by #310 — duplicates are gone, a one-message thread now costs 3 requests instead of 201, and latency dropped from ~30s to ~0.5s. Thanks for the quick turnaround.
Two symptoms from that report did not travel with the cursor fix, and #279 was closed as completed, so filing them separately and more narrowly. My original write-up presented all three together, which probably obscured that they had different causes.
1.
attachment listreports 0 for threads that do have attachmentsSweeping every thread that HEY's own search flags as carrying a PDF, over the last 30 days:
So 17 of 30 fail. The zero case is not search over-matching. Opening four of the zero threads in the web app and counting distinct
active_storage/blobslinks in the rendered DOM:The search filter itself is trustworthy — as controls, two senders whose mail carries no PDF return no matches at all:
attachment saveoffers no way around it, since it resolves ids through the same listing:Full set of threads reporting 0 while search says they carry a PDF:
There is no way to tell this apart from a genuinely attachment-free thread — both report
0.2.
API error: 500 Internal Server Erroron some threadsFour threads in the same sweep fail outright rather than returning a wrong count:
Reproducible on every run. These also returned 500 on
0.1.1, so this predates the cursor change and is unrelated to it.Both against
1.2.1(58c83f1), macOS, release install.