Question: Scaling listener pod replicas to avoid single point of failure

[sundeepgarg]

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

10.0.1

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

I want to know if replica of listener pod can be increased to two instead of default one so that we can avoid single point of failure.

Specifically, I am concerned about the following:
- Can increasing the number of listener pod replicas to two lead to a race condition?
- Will both listeners listen to the same job, potentially causing the same job to run twice?
- Is there any listener pod election, or will both listener pods run at the same time?
- Is increasing the listener pod to two a good idea, or could it introduce unwanted side effects?

Please provide guidance on best practices for scaling the listener pod and any potential risks or mitigations involved.

Describe the bug

I want to know if replica of listener pod can be increased to two instead of default one so that we can avoid single point of failure.

Specifically, I am concerned about the following:

• Can increasing the number of listener pod replicas to two lead to a race condition?
• Will both listeners listen to the same job, potentially causing the same job to run twice?
• Is there any listener pod election, or will both listener pods run at the same time?
• Is increasing the listener pod to two a good idea, or could it introduce unwanted side effects?

Please provide guidance on best practices for scaling the listener pod and any potential risks or mitigations involved.

Describe the expected behavior

I want to know if replica of listener pod can be increased to two instead of default one so that we can avoid single point of failure.

Specifically, I am concerned about the following:

• Can increasing the number of listener pod replicas to two lead to a race condition?
• Will both listeners listen to the same job, potentially causing the same job to run twice?
• Is there any listener pod election, or will both listener pods run at the same time?
• Is increasing the listener pod to two a good idea, or could it introduce unwanted side effects?

Please provide guidance on best practices for scaling the listener pod and any potential risks or mitigations involved.

Additional Context

I want to know if replica of listener pod can be increased to two instead of default one so that we can avoid single point of failure.

Specifically, I am concerned about the following:
- Can increasing the number of listener pod replicas to two lead to a race condition?
- Will both listeners listen to the same job, potentially causing the same job to run twice?
- Is there any listener pod election, or will both listener pods run at the same time?
- Is increasing the listener pod to two a good idea, or could it introduce unwanted side effects?

Please provide guidance on best practices for scaling the listener pod and any potential risks or mitigations involved.

Controller Logs

I want to know if replica of listener pod can be increased to two instead of default one so that we can avoid single point of failure.

Specifically, I am concerned about the following:
- Can increasing the number of listener pod replicas to two lead to a race condition?
- Will both listeners listen to the same job, potentially causing the same job to run twice?
- Is there any listener pod election, or will both listener pods run at the same time?
- Is increasing the listener pod to two a good idea, or could it introduce unwanted side effects?

Please provide guidance on best practices for scaling the listener pod and any potential risks or mitigations involved.

Runner Pod Logs

I want to know if replica of listener pod can be increased to two instead of default one so that we can avoid single point of failure.

Specifically, I am concerned about the following:
- Can increasing the number of listener pod replicas to two lead to a race condition?
- Will both listeners listen to the same job, potentially causing the same job to run twice?
- Is there any listener pod election, or will both listener pods run at the same time?
- Is increasing the listener pod to two a good idea, or could it introduce unwanted side effects?

Please provide guidance on best practices for scaling the listener pod and any potential risks or mitigations involved.