Repository navigation
Unable to view job logs gh run view --log #11059
Description
Activity
Thanks for reporting this, @ptorgalmath-gpsw! 🙏
As you mentioned the same issue with GUI, it has to do with the API server and the network mechanics.
However, even if the logs are successfully downloaded, a malfunction at
ghside is technically possible. When you rungh run view --log,ghdownloads the ZIP archive logs from the API and stores it in its cache directory (e.g.~/.cache/ghon Unix/Linux). The file name is formatted asrun-log-99999999999-9999999999.zip. That is why the next time you run the samegh run view --logcommand, it'll take much less time displaying the logs.When the download is done,
ghfinds the right job run within the ZIP archive, prefixes the lines with job/step name fields, and finally pipes them to stdout which is piped into the stdin of a pager (lessby default on Unix/Linux). And this is where we may see problems, because we're pushing all log content to the stdin of another process (the pager), and seeing the problem really depends on the host resources (e.g. memory), and the way the pager handles large inputs.Anyway, I tested
ghwith a syntactic 500M log file (363M ZIP file), and despite a few seconds lag when you jump to the end of the log stream,ghandlesswork nicely together. Again, it depends on various parameters.Now, @ptorgalmath-gpsw, can you please tell me what's your experience with
ghwhen the initial download is successful? You can checkghcache directory to see if the ZIP file is there.I'm facing the same issue and did some digging.
- The zip file is downloaded correctly, but seems like
ghis unable to unzip it. - Running
unzipmyself, I get someIllegal byte sequencemessages. - Following this stackoverflow post it seems like the
unziputil on mac is quite old. - Downloading unar extracts it just fine.
- The zip file is downloaded correctly, but seems like
I'm guessing there's some kind of error that is swallowed, I'm getting no output.
Screen.Recording.2025-06-16.at.15.03.47.mov
Also, the exit status is 0.
Viewing the check on the web works fine:
@babakks I think I found the issue, but not sure if the fix will break other stuff.
In https://github.com/cli/cli/blob/trunk/pkg/cmd/run/view/view.go?plain=1#L552, if I swap it like so, the issue is fixed:- sanitizedJobName := strings.ReplaceAll(name, "/", "") + sanitizedJobName := strings.ReplaceAll(name, "/", "_")
The job name in my case is
Run frontend tests / Cypress 4 🌲.
And the file name in the zip is12_Run frontend tests _ Cypress 4 🌲.txt.
ghcurrently looks for a file named12_Run frontend tests Cypress 4 🌲.txtwhich it obviously doesn't find.
Maybe the logic in the server that produces these files changed?Reacted by Babak K. ShandizThanks for details, @dlvhdr! 🙏
Yeah, the problem can be the way the Actions backend sanitises file names in the ZIP archive. We have already captured this in #10868, and @williammartin and I are working on a fix that will help with your case as well.
Unfortunately, your suggestion is a breaking change. Currently, the ZIP archives are served by two versions of a backend service and they're not exactly producing the same ZIP structure. As said, we're working on a fix that will probably help with this case.
Reacted by Dolev HadarWell, I think we should probably accept either character. Even with the fix we have, we should always endeavour to find the log files in the zip file for performance and availability reasons.
Reacted by Babak K. Shandiz and Dolev HadarYeah, definitely. That's what the other issue is about.
1 remaining item
@ptorgalmath-gpsw, this error means the other party (server) has cancelled the stream. That's why you don't see a ZIP file created under
~/.cache/gh.The first step is to make sure this termination has anything to do with the Go HTTP client that
ghis using.To verify this, you can try downloading the archive via the following
curlcommand:curl -L \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer $(gh auth token)" \ -H "X-GitHub-Api-Version: 2022-11-28" \ -o run-log.zip https://api.github.com/repos/OWNER/REPO/actions/runs/RUN_ID/logsNote that you should replace
OWNER,REPOandRUN_IDwith the right values. Also$(gh auth token)already inserts your auth token.If
curlcan download the ZIP archive, then we need to dig deeper and see what's going on with Go HTTP client. Ifcurlcouldn't, then there's something with the platform infra that is killing the stream.Could you please try the command above and share your observations, @ptorgalmath-gpsw?
It failed to download the ZIP archive, here's what I see
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 18.7M 0 18.7M 0 0 627k 0 --:--:-- 0:00:30 --:--:-- 1318k curl: (92) HTTP/2 stream 1 was not closed cleanly: CANCEL (err 8)
cc: @babakksThis seems like a network/infra issue. Could you please retry
curlwith--http1.1to enforce HTTP/1.1?I still get an error
curl: (18) transfer closed with outstanding read data remaining. So you think this could be something on my MacBook causing this?
cc: @babakksThanks for checking out, @ptorgalmath-gpsw! 🙏 I can't rule out that possibility, but it seems remote.
As I'm checking online resources, this can happen due to an incorrect
Content-Lengthheader value sent by the server. Can you please trycurlagain with--ignore-content-lengthoption?Unfortunately that flag didn't help either, I'm also working with our IT to figure out if it's something we are enforcing. Here's the error with flag
--ignore-content-length
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 27.1M 0 27.1M 0 0 908k 0 --:--:-- 0:00:30 --:--:-- 1140k curl: (18) transfer closed with outstanding read data remainingAlso it always times out at 30 secs.
cc: @babakks
Worked with our IT, it doesn't look like the issue is from our IT blocking the download, just wanted to update.
I tried on a non company device and the result was the same using browser download via GitHub.com. So we can rule out our IT blocking us from downloading the file.
Thanks again for helping us isolate the problem, @ptorgalmath-gpsw! 🎉
As of our internal comms, there actually is an intentional timeout here, which confirms your observation. But it's not clear if that's going to be changed/improved. So, I'm going to label this issue as platform related case, as there's nothing
ghcould do at the moment.As an alternative solution to unblock you, since you're trying to get the logs for a specific job, you can use
gh apito directly fetch the job logs from the API. However, the result will not be as nice asgh run view --logoutput. Here's the command:gh api /repos/OWNER/REPO/actions/jobs/JOB-ID/logs
Where
OWNER,REPO, andJOB-IDhave to be replaced with the right values.Thanks for the update. The api works fine, for now I can get logs via gh api but can we try to find a resolution to downloading logs via web browser or gh run? thanks
Reacted by federicoarcangeliWe've brought it up with the team that owns the service that provides the logs but in practice, they need to pick some limit and whatever limit they pick will impact some amount of people depending on internet speed and total log size. Do you have any idea how big your total log zip might be? You're getting cut off at around 27MB since you're downloading a little under 1MB per second and hit the 30 second limit.
I'm not sure where you are located? Is 1MB/s surprisingly low? Maybe you could do a speedtest elsewhere and see what you get.
Some further investigation makes me think there is something suspicious happening on the server, as I get timed out at a similar amount downloaded, despite speedtest.net showing me working at 10x this speed.
➜ test-repo git:(main) curl -L \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer $(gh auth token)" \ -H "X-GitHub-Api-Version: 2022-11-28" \ -o run-log.zip \ https://api.github.com/repos/williammartin/test-repo/actions/runs/16193257615/logs % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 35.6M 0 35.6M 0 0 1194k 0 --:--:-- 0:00:30 --:--:-- 751k curl: (92) HTTP/2 stream 1 was not closed cleanly: CANCEL (err 8)Will bring this back to the team that owns the service.
Reacted by Babak K. Shandizyes @williammartin you are right, my speed test also returned 10x but the timeout is set to a certain amount, doesn't matter how fast the download is it times out because the logs are huge. So far the biggest ZIP that I was partially able to download was 80MB. I'm also working with the team to get log size reduced because it is mostly warnings. But to me 30secs seems too quick to stop the download. Is there any other forum I need to open a ticket or ask about this so it has visibility? Thanks.
You could raise a support ticket through your organisation's plan, if you have that option, that might help it get prioritised.
Reacted by Priyanka Torgalmath
Describe the bug
Running gh run view --log --job #jobNumber results in failure for logs of bigger size. This issue also occurs when downloading logs archives via GitHub webpage for the workflow.
Affected version
gh version
gh version 2.74.0 (2025-05-29)
https://github.com/cli/cli/releases/tag/v2.74.0
Steps to reproduce the behavior
Expected vs actual behavior
Error while trying to view logs for a job and the same issue occurs via GitHub.com as well, tried on chrome and safari. On safari after downloading for sometime I get 'The network connection is lost'. In some cases retrying the download archive works but CLI fails for specific jobs(I suspect it's to do with large log size). Log sizes are ~500MB for some workflows.