Intermittent Issues with Connector Hanging

[hisaac]

We're currently using this project to connect our Orka environment to GitHub Actions. To do this, I'm running this app in two containers using Podman on a Linux machine.

We're seeing intermittent issues where the connector seems to stop working temporarily. GitHub Actions workflows will sit queued for a long period of time with no runners being made available to them.

Some more details from when this last occurred:

• When viewing the list of runners within GitHub's web UI, the scale set appears as active in the list, but there are several runners in the list, and they all say "offline". Perhaps their not being cleaned up correctly?
• When viewing the logs from the container, I see the same message printed many times:

  {"level":"debug","ts":"2025-12-16T15:16:11Z","logger":"http-client","msg":"performing request","method":"GET","url":"https://broker.actions.githubusercontent.com/scalesets/message?lastMessageId=100008133"}
  

My workaround right now is to kill the Podman container and restart it, which seems to unclog things.

Any ideas what's going on here, or what I could do to mitigate this going forward? It seems to happen every few days.

[owenmartin-toast]

Hi @hisaac - do you have other runners/labels configured for your Default runner group?
We're just spinning up the GHA integration, and ran into the same problem, but once we set up a dedicated runner group per label, the issue went away

[hisaac]

We do indeed have other runners configured for the default runner group!

I'll give that suggestion a try and see if it improves things. Thank you for the tip. 🙏

[owenmartin-toast]

FWIW, whether this is the same underlying problem or another one, I did find that VMs were being deleted before they could be de-registered from GitHub. That left the Scale Set believing it had an available runner for jobs, and therefore wouldn't provision new ones.
I've opened #51 with a change that fixed things in my environment by checking that the de-registration happened before deleting the VM