start-runner step sometimes fails to start

[hosua]

Hello, and thank you for this maintaining this action

I recently added self-hosted runners to my workflow for pull request checks, but it seems to sometimes have issues with starting the tasks.

In the start-runner step of the workflow, it gets stuck on checking...

I was having this issue with the default 5 minute timeout period, so I tried bumping it up to 10 minutes but did not have any luck with that.

My currently workflow consists of running 12 jobs in parallel (it tests multiple parts of the codebase asynchronously). It always seems that only one of them fails every time it happens (11 out of 12 tests pass every time I run into this issue). It also doesn't happen every time. If I had to guess, it happens once every 4-5 times I've tried using the workflow.

Is there maybe an issue with starting so many EC2 instances at once? Sorry if this is not a bug with this action in particular, I'm not really sure what the actual issue is.

[humzam]

When I saw this issue happen in our organization most recently, registration failed due to runner name conflicts. Because by default the runner names are based off IP addresses (which can be re-used), occasionally we could get a runner with the same IP address as one we previously created & destroyed.

Normally this shouldn't be a problem, if you are properly stopping / de-registering all your old runners. But we got into a situation where we had tons of orphaned runners sitting around which increased the likelihood of hitting a name conflict.

Maybe you could check if you have several "offline" runners in your org?

[humzam]

Related, there's an open PR right now that could solve this issue, if it is indeed the same issue

• Avoid failures when other runners are already registered with same name #127

[hosua]

When I saw this issue happen in our organization most recently, registration failed due to runner name conflicts. Because by default the runner names are based off IP addresses (which can be re-used), occasionally we could get a runner with the same IP address as one we previously created & destroyed.

Normally this shouldn't be a problem, if you are properly stopping / de-registering all your old runners. But we got into a situation where we had tons of orphaned runners sitting around which increased the likelihood of hitting a name conflict.

Maybe you could check if you have several "offline" runners in your org?

Actually, I did run into the same issue as well and had to delete a few IP addresses on there earlier today. Perhaps those ended up there when I was setting up the runner.

I'm not 100% sure if that solves the issue yet but if I don't see the issue anymore after a while, I can probably close this ticket.

Thanks for responding!

[hosua]

Going to close this ticket, as this seems to have been what the issue was. Thank you @humzam!