Log lines for an active step are inaccessible

[bogosj]

Describe the bug
When opening the "run" page for an active job you can see:

• Gray checkmarks and expandable sections for completed steps and all of their log lines.
• Yellow loading animation on any active steps.
• Circles for the future steps.

The log lines for the active steps will then start streaming in, but the prior lines for that step are not there, and there appears to be no way to see them until the step completes.

To Reproduce
Steps to reproduce the behavior:

1. Run an action
2. Visit the run page after a few seconds and try to find the log lines for the currently running step that occurred before you loaded the page.

Expected behavior
All of the log lines that were emit before I loaded the page should be visible, then new ones stream in afterwards.

[bogosj]

It looks like this is a KI, but I can't find a canonical bug tracking it:

mxschmitt/action-tmate#1 (comment)

[konradpabjan]

👋 Actions engineer here

So I wouldn't classify this as a bug, but it's just a missing feature.

When a step is running, you can do "inspect element", and see that there is a active websocket that is streaming in new output from the runner. When a step is completed though, a GET request is made to our service that downloads all the logs for step in one go. If a step is in-progress and a user refreshes a page or first loads a page while it is in-progress, the logs that were already streamed to the websocket are effectively gone until the step is completed and we can fetch everything using an internal GET api.

The solution for us is to somehow cache existing logs that have already been streamed and if a user refreshes a step that is in-progress, fetch the cached logs and display that + append new logs that are coming in through the websocket.

We'll eventually add this feature (this would be really really nice to have), but at the moment we just haven't been able to pick this up.

[vadi2]

This would be great to have because some steps can take a while, or in fact due to error get stuck for a good half hour - and you're sitting there wondering if you should cancel it or not. It comes up often as a problem during development of your workflow!

[TingluoHuang]

I believe this is on our backlog.

[graeme-verticalscope]

yeah this would be nice to have 😃

[ethomson]

Hi! This seems like a possibly useful addition. However, suggestions for GitHub Actions functionality belong in the GitHub feedback forum, where the product managers and engineers will be able to review them. This repository is really only focused on the runner application, which is a very small component of GitHub Actions.

We do have this opened on our backlog, so I'm going to close this issue here. Thanks again!

[charlesritchea]

This is basic CI functionality, so it's a bug. I don't know how you could classify it as a nice to have feature. Sounds like you aren't in the trenches having to diagnose builds much

[FranDepascuali]

I'm suffering this right now :p.
This is the only thing I'm seeing, it has been a long time and I have no way of diagnosing what's happening

Update: 1hr 42min, make your bets!

[schipperkp]

I agree with the thought process that this is not nice to have but a must-have. If you're working on debugging a prod deploy that has gone south, you may not be able to cancel the build, but rather you must let it complete the rollback steps. This means you lose valuable time and information by needing to wait...

[schipperkp]

@ethomson can we get a link to the backlog Item in this thread?

[umm0n]

As others have commented, I don't see this as a nice-to-have but rather, an elemental feature. A link to the backlog feature would be nice!