[GH-ISSUE #4684] [Feature Request] loopLoginUntilSuccess Flag in ClientCommonConfig to decide to keep retrying to connect to server or exit

gitea-mirror commented

2026-05-05 14:22:15 -06:00

Owner

Copy link

Originally created by @smodhave on GitHub (Feb 21, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4684

Describe the feature request

I’m working on a project where I need multiple Kubernetes pods with FRP clients for high availability, but only one should be connected to the server by acquiring a lease. These pods are distributed across different availability zones.

There might be scenarios where the network in the availability zone of the pod that has acquired the lease goes down. In such cases, the FRP client will retry indefinitely, and the pod will not be able to release the lease because no error is thrown.

Additionally, there could be other situations where the user needs to take control and implement their own logic before retrying the connection if necessary.

Describe alternatives you've considered

Instead of loopLoginUntilSuccess flag, we can also have maxLoginRetries attribute.

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @smodhave on GitHub (Feb 21, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4684 ### Describe the feature request I’m working on a project where I need multiple Kubernetes pods with FRP clients for high availability, but only one should be connected to the server by acquiring a lease. These pods are distributed across different availability zones. There might be scenarios where the network in the availability zone of the pod that has acquired the lease goes down. In such cases, the FRP client will retry indefinitely, and the pod will not be able to release the lease because no error is thrown. Additionally, there could be other situations where the user needs to take control and implement their own logic before retrying the connection if necessary. ### Describe alternatives you've considered Instead of loopLoginUntilSuccess flag, we can also have maxLoginRetries attribute. ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [x] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [x] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:22:15 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:22:18 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Feb 24, 2025):

I don’t think this is the right way. You usually need to redesign your entire architecture to solve the problem.

@fatedier commented on GitHub (Feb 24, 2025): I don’t think this is the right way. You usually need to redesign your entire architecture to solve the problem.

gitea-mirror commented

2026-05-05 14:22:19 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Mar 11, 2025):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Mar 11, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

No Branch/Tag specified