listWorkflowRuns calls fail without any logging

[rajbos]

Describe the bug
Any calls to (at least) the endpoints below fail, without any feedback to debug with

• octokit.rest.actions.listWorkflowRunsForRepo
• octokit.rest.actions.listWorkflowRuns
  I also tested with octokit.rest.actions.getWorkflow and that does work, so not everything under actions is failing. Even placing the call within a try/catch and enabling ACTIONS_STEP_DEBUG I don't get any feedback on what is happening and I am lost how to debug further. Also tried to make the calls myself in Postman and those work, so I halfway expecting something in the response handling for this.

Also tried running the request directly in octokit, but this has the same result: no error, but also no logging:

           const response = await octokit.request(
                "GET /repos/{owner}/{repo}/actions/runs",
                {owner, repo}
            )        
            console.log(`Response: ${JSON.stringify(response)}`)

Logging

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
At least an error with more info would be nice :-D

Additional context
See the workflow run here: https://github.com/rajbos/demo-actions/runs/4441569964?check_suite_focus=true

[github-actions]

This issue is stale because it has been open for 60 days with no activity. Remove the "Stale" label or comment on the issue, or it will be closed in 7 days.

[rajbos]

Thanks for not helping Bot :-D. Adding comment to keep it alive ;-)

[joshmgross]

👋 @rajbos are you still having issues?

[rajbos]

I've been trying to reproduce, but getting correct 404's now. I think most of the issues I had stem from the fact that the ${{ github.workflow }} contains the full name of the workflow file, untill you give the workflow a name. Then all of a sudden the ${{ github.workflow }} returns the name, instead of the filename I was using before.

I've changed that part to use the ${{ github.workflow_ref }} and parse that, which works since the workflows are stored in a predictable path.

Closing this issue then.