Render action randomly fails when exporting to PDF: ERROR: Couldn't find open server

[rogerbramon]

Occasionally, quarto-actions/render@v2 fails to run, causing ERROR: Couldn't find open server. I've only experienced this problem when rendering to PDF, HTML output seems fine.

Has anyone experienced it?

Tested on:
Ubuntu 20.04 and 22.04
Quarto: latest version (1.1.189) and fixing one (1.0.37)

Workflow example:

name: Generate PDF
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled]

jobs:
  generate-pdf:
    - name: Setup Quarto
      uses: quarto-dev/quarto-actions/setup@v2
      with:
        tinytex: true

    - name: Quarto check
      run: |
        quarto check --log-level info

    - name: Render Quarto Project
      uses: quarto-dev/quarto-actions/render@v2
      with:
        to: pdf
        path: input/P123-qmd-file.qmd

This is the output of all Quarto actions of the workflow when fails:

[cderv]

This error does not ring a bell to me. @cscheid did you already encountered such error ?

@rogerbramon can you share more on the .qmd content where this error happens ? Do you have a link of the project ?

[cscheid]

This is the first time I see this error. Thank you for the report!

[rogerbramon]

@rogerbramon can you share more on the .qmd content where this error happens ? Do you have a link of the project ?

Content is basically pure Markdown and a mermaid diagram using ```{mermaid} format.
Unfortunately, it's a private repo, but I could try to create a test one and try to reproduce it there.

[cderv]

And a mermaid diagram using ```{mermaid} format.

I think this could come from that content. For PDF output, it needs to be printed to image using Chrome or Chromium. And it seems this cause issue (with server not found)

Google Chrome should be installed on GHA runners, but it seems something is not working as expected.

I could try to create a test one and try to reproduce it there.

If you do a test repo to reproduce, that will be really useful to reproduce and investigate

[rogerbramon]

Here you have the test repo, and I was able to reproduce the problem at the 3rd attempt (same code, just re-run jobs).

Successful attempt: https://github.com/rogerbramon/test-quarto/actions/runs/3045981181/attempts/2
Failure attempt: https://github.com/rogerbramon/test-quarto/actions/runs/3045981181

[cderv]

Thanks a lot!

I was able to reproduce the problem at the 3rd attempt (same code, just re-run jobs).

It seems not good that this is working on some run, and not on other... Like internal issue in the runners with connecting to chrome headless. 🤔

[rogerbramon]

Could it be that sometimes the Google Chrome takes a bit longer to spin up? If I get it right, you have a timeout of only 3 seconds on waitForServer.

https://github.com/quarto-dev/quarto-cli/blob/ed57d10eba33c34b5e1df2c22ed372a7e28da5d0/src/core/cri/cri.ts#L80-L90

I tried adding a previous step that calls the Chrome headless, and the problem is not occurring then. That's why timeout is my guess... Any thoughts?

    - name: Check chrome
      run: |
        echo $(which google-chrome)
        $(which google-chrome) --headless --single-process https://www.chromestatus.com

[cscheid]

Somewhat disconcertingly, the only hit on google for that error is another open issue on quarto quarto-dev/quarto-cli#1822

[cderv]

Oh interesting. Thanks @cscheid !

I am still trying to find a clean environment to reproduce the issue as now it working in my WSL, after I install the deb google-chrome. I just don't know the change. Before that I could reproduce each time though...

here it is also an error in Ubuntu in GHA. Maybe this will help us find the reason if I manage to debug this in the workflow directly.

[rogerbramon]

@cderv, you may use the action-tmate action to get access to the runner system via SSH and debug there.

[rogerbramon]

Just to add a bit of info, I've also experienced this problem on macOS a couple of times. But it's much more difficult to reproduce.

Not sure if that adds noise or are different issues, but besides the Couldn't find open server sometimes I also get on macOS:

• ERROR: No inspectable targets

It's not easy to reproduce, but it's easier to get the error when there's no instance of Google Chrome opened.
HTH

[cderv]

So I manage to reproduce locally for quarto-dev/quarto-cli#1822 - the issue there is systematic not occasional and probably due to missing system requirement for the chromium that we install from puppeteer. I believe Github action has it all so not the issue here because occasional also.

Somewhat disconcertingly, the only hit on google for that error is another open issue on quarto

By the way this is the only hit because this is an error thrown by Quarto
https://github.com/quarto-dev/quarto-cli/blob/ed57d10eba33c34b5e1df2c22ed372a7e28da5d0/src/core/cri/cri.ts#L91

When the https://localhost:<port> can't be reach withing the timeout limit we through an error. This can happen if there is an issue with launching chrome or if chrome running. Currently we throw only the error.

I have made a PR in Quarto so that we can have more information if the error is a failed attempt to run chrome.
See quarto-dev/quarto-cli#2499

If I get it right, you have a timeout of only 3 seconds on waitForServer.

We could indeed look in the timeout. However, I think we attempt already 60 times with 50s between each attempt.

Maybe quarto-dev/quarto-cli#2499 will show some issue with running chrome itself and not with timeout. It should be merged soon and available in a pre-release to use it.

ERROR: No inspectable targets

@rogerbramon this issue is thrown by quarto also when targets are not valid somehow for the chrome remote interface. It means the chrome was launched correctly, quarto connected correctly to the remote debugging port, but... there is something else not correct in the interaction with the headless browser. If you have an example to share where this happens, that would help

[rogerbramon]

Thanks @cderv for your time. I tried the latest pre-release version (1.2.134) on the testing repo and, unfortunately, I've not been able to get the error because the render step now hangs (3 of 7 attempts). I had to cancel the workflow after 5min.

https://github.com/rogerbramon/test-quarto/actions/runs/3088361081/jobs/4994835499

Regarding the No inspectable targets, I have no further info to share, it occurred when running the same render command on the macOS.

[cderv]

That is bad. It is probably a different issue than quarto-dev/quarto-cli#1822 - I'll look into that next;