Actions logs API: server aborts /runs/{id}/logs download at ~30 s for large run zips

[yarikoptic]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

Pre-history:

Our https://github.com/con/tinuous/ started to fail to download our https://github.com/dandi/dandi-cli CI logs a few days. Very consistently failing but varying in how much it reported "not fetched":

2026-04-24T20:00:39-0400 [WARNING ] tinuous: Download of https://api.github.com/repos/dandi/dandi-cli/actions/runs/24899963531/logs interrupted: ('Connection broken: IncompleteRead(3756 bytes read, 340 more expected)',        
IncompleteRead(3756 bytes read, 340 more expected)); waiting & retrying                                                                                                                                                           
2026-04-24T20:01:10-0400 [WARNING ] tinuous: Download of https://api.github.com/repos/dandi/dandi-cli/actions/runs/24899963531/logs interrupted: ('Connection broken: IncompleteRead(1044 bytes read, 3052 more expected)',       
IncompleteRead(1044 bytes read, 3052 more expected)); waiting & retrying    

enhancing logging gave larger picture that it was some tail of the file and the file was zip:

2026-04-24T22:36:26-0400 [DEBUG   ] urllib3.connectionpool: https://api.github.com:443 "GET /repos/dandi/dandi-cli/actions/runs/24899963531/logs HTTP/1.1" 302 0
2026-04-24T22:36:26-0400 [DEBUG   ] urllib3.connectionpool: https://results-receiver.actions.githubusercontent.com:443 "GET /rest/runs/4283241d-41a3-4913-8d89-33f36af6b000/logs?filename=logs_66077725578.zip&signature=1777084586.fcd8a107eba485d770981278b4fb5856c60f1bc1e27c06505ede1b116ac8cf1a HTTP/1.1" 200 None
2026-04-24T22:36:56-0400 [WARNING ] tinuous: Download of https://api.github.com/repos/dandi/dandi-cli/actions/runs/24899963531/logs interrupted after 60764160 bytes: ('Connection broken: IncompleteRead(3996 bytes read, 100 more expected)', IncompleteRead(3996 bytes read, 100 more expected)); response headers: {'content-disposition': 'attachment; filename=logs_66077725578.zip', 'Content-Type': 'application/zip', 'Date': 'Sat, 25 Apr 2026 02:36:26 GMT', 'Transfer-Encoding': 'chunked', 'x-github-backend': 'Kubernetes', 'X-GitHub-Request-Id': '9BEA:1C5FC0:E164B65:FB7862E:69EC28A7'}; partial preview (first 512 bytes): b'PK\x03\x04\x14\x

a number of direct curl attempts ended with 30 second cut off marks:

< 
{ [1102 bytes data]
100  155M    0  155M    0     0  5436k      0 --:--:--  0:00:29 --:--:-- 2504k* TLSv1.3 (IN), TLS alert, close notify (256):
{ [2 bytes data]
* transfer closed with outstanding read data remaining
100  156M    0  156M    0     0  5308k      0 --:--:--  0:00:30 --:--:-- 1607k
* closing connection #1
curl: (18) transfer closed with outstanding read data remaining

bytes=164211300

here is claude produced summary to report, which I reviewed and even "Ask" section made sense to me:

Summary

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs aborts mid-stream at a
~30 second wall-clock cutoff when the run-logs zip is large, making the full
zip unretrievable from networks that can't transfer it within that budget.
The cutoff is server-side and independent of HTTP version.

Reproducer

Repo: dandi/dandi-cli (public)
Run: 24899963531
Endpoint: GET /repos/dandi/dandi-cli/actions/runs/24899963531/logs

curl -L -o logs.zip \
  -H "Authorization: Bearer $GH_TOKEN" -H 'Accept: */*' \
  https://api.github.com/repos/dandi/dandi-cli/actions/runs/24899963531/logs

100% reproducible from a Dartmouth host (129.170.233.10). Earlier runs of
the same workflow downloaded successfully.

Evidence — same 30 s cutoff, two protocols, two failure modes

HTTP/2: server sends RST_STREAM(CANCEL, err 8) after ~30 s.

• bytes received: 53,793,996 (~51 MiB)
• effective rate: ~1.7 MB/s
• curl tail:

  * HTTP/2 stream 1 was not closed cleanly: CANCEL (err 8)
  curl: (92) HTTP/2 stream 1 was not closed cleanly: CANCEL (err 8)
  

HTTP/1.1 (--http1.1): server closes connection with body still pending.

• bytes received: 164,211,300 (~156 MiB)
• effective rate: ~5.2 MB/s
• curl tail:

  * transfer closed with outstanding read data remaining
  curl: (18) transfer closed with outstanding read data remaining
  

Both attempts terminate at ~30.0 s time_total. The HTTP/1.1 attempt got
~3× more bytes simply because the stream ran faster, which rules out a byte
limit and points to a wall-clock budget on the response generation.

Mitigations attempted (none viable)

• Range: bytes=0-52428799 request: server returns 200 OK (not 206),
  no Content-Range, no Accept-Ranges — Range header is ignored, so a
  range-based client mitigation cannot work on this endpoint.
• Per-job endpoint /repos/.../actions/jobs/{job_id}/logs does work
  (smaller payloads finish in <30 s), but it is not a substitute for the
  run-level zip API which is documented as the canonical bulk-fetch path.

x-github-request-id values from failed attempts

• 8748:131578:174B0DD:1B3E419:69EC272B (HTTP/2)
• E314:16A6CA:E27B2CF:FCB0AED:69EC2B48 (HTTP/2)

Ask

1. Confirm the ~30 s budget on this endpoint and whether it's intentional.
2. If intentional, please publish it and ideally support Range so clients
   can chunk; otherwise the endpoint is unusable for any sufficiently large
   run from any sufficiently slow network path.
3. Investigate whether logs zips that exceed the budget are simply
   unreachable for affected clients.

Environment

• Client: curl 8.14.1 (HTTP/2) and curl 8.14.1 --http1.1
• Also reproduced with python-requests 2.33.1 / urllib3 2.6.3
• Source IP: 129.170.233.10 (eth0, MTU 1500, no jumbo on the egress path)
• TLS 1.3, *.github.com cert valid

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[yarikoptic]

I didn't find any relevant info among provided references.