Listener metrics missing gha_available_jobs and gha_acquired_jobs from RunnerScaleSetStatistic

[PrateekKumar1709]

Checks

• I've already read https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/troubleshooting-actions-runner-controller-errors and I'm sure my issue is not covered in the troubleshooting guide.
• I am using charts that are officially provided

Controller Version

0.14.0

Deployment Method

Helm

Checks

• This isn't a question or user support case (For Q&A and community support, go to Discussions).
• I've read the Changelog before submitting this issue and I'm sure it's not due to any recently-introduced backward-incompatible changes

To Reproduce

1. Deploy ARC with listener metrics enabled
2. Scrape the listener's /metrics endpoint
3. Observe that `gha_assigned_jobs`, `gha_running_jobs`, `gha_registered_runners`, `gha_busy_runners`, and `gha_idle_runners` are present
4. Note that `gha_available_jobs` and `gha_acquired_jobs` are missing despite the data being available in `RunnerScaleSetStatistic`

Describe the bug

The RunnerScaleSetStatistic struct from github.com/actions/scaleset provides 7 fields, but RecordStatistics() in cmd/ghalistener/metrics/metrics.go only exposes 5 of them as Prometheus gauges. Two fields — TotalAvailableJobs and TotalAcquiredJobs — are silently dropped.

The metrics ADR (docs/adrs/2023-05-08-exposing-metrics.md) explicitly proposed available_jobs and acquired_jobs as listener metrics, but they were never implemented.

RunnerScaleSetStatistic field	Listener metric	Status
TotalAvailableJobs	—	Not exposed
TotalAcquiredJobs	—	Not exposed
TotalAssignedJobs	gha_assigned_jobs	Exposed
TotalRunningJobs	gha_running_jobs	Exposed
TotalRegisteredRunners	gha_registered_runners	Exposed
TotalBusyRunners	gha_busy_runners	Exposed
TotalIdleRunners	gha_idle_runners	Exposed

Without these metrics, operators cannot observe the job queue depth for their scale sets.

Describe the expected behavior

All 7 fields from RunnerScaleSetStatistic should be exposed as listener metrics. Specifically:

• gha_available_jobs — number of jobs with matching runs-on labels waiting to be acquired by the scale set
• gha_acquired_jobs — number of jobs acquired by the scale set but not yet assigned to a runner

These represent the job queue depth (available + acquired = jobs waiting for runners) and are essential for capacity planning and monitoring.

Additional Context

N/A - This is a code-level issue. The data is already flowing from the Actions service
through the listener via RunnerScaleSetStatistic. The fix is purely additive: define two
new gauge metrics and wire them in RecordStatistics(). No CRD, interface, or dependency
changes required.

Controller Logs

N/A - This is not a runtime bug. It is a missing metric implementation identified through
code review. The relevant code is in cmd/ghalistener/metrics/metrics.go RecordStatistics().

Runner Pod Logs

N/A - See above. No runtime reproduction needed.

[github-actions]

Hello! Thank you for filing an issue.

The maintainers will triage your issue shortly.

In the meantime, please take a look at the troubleshooting guide for bug reports.

If this is a feature request, please review our contribution guidelines.

[nikola-jokic]

Hey @PrateekKumar1709,

I'm not sure we want to expose these metrics anymore. We might want to update the ADR, but the way the API works now, it doesn't make sense to expose these metrics.

Previously, the listener would get offered jobs, try to acquire them, and once they are acquired, we would start running them. This has been changed in 0.9.2 version where we started communicating the capacity information of the scaleset. Now, when the listener asks for jobs, it tells the API what capacity it has (in other words, how many jobs it can handle based on the configuration). The server will assign jobs based on the capacity, reducing the number of calls and making it faster. Therefore, available jobs and acquired jobs don't make much sense anymore.

I do understand that the previous way would help measure the queue depth, however, assigning right away is way quicker than offering jobs, acquiring them and later running them once they are acquired. I will close this issue now, but we should definitely update the ADR to express that.