Jenkins has a notion of the 'oldest supported remoting version', which amounts to the oldest remoting versions a Jenkins controller is tested against, that's all fair enough.
For those who want to take the risk of using an untested remoting version, the system property hudson.slaves.SlaveComputer.allowUnsupportedRemotingVersions is provided. Which tells the controller to allow agents to connect even if they are using an untested version.
There's a problem however, this code in the remoting https://github.com/jenkinsci/remoting/blob/master/src/main/java/hudson/remoting/Engine.java#L624 unconditionally checks the version the controller said is the minimum supported version, and won't try to make a connection if it is below it (i.e. in reality the controller would accept the request if the agent made it, but it never gets to that point).
Ultimately in my context I have worked around this, by using istio to modify the X-Remoting-Minimum-Version header supplied by the controller in the initial request from agent to controller.
It seems to me that this is a bug, and there should be a way to let agents know to try to use an old version.
Originally reported by thrillpool, imported from: No facility to try unsupported Remoting versions when using inbound agents
- assignee: basil
- status: Closed
- priority: Minor
- component(s): core
- label(s): regression
- resolution: Fixed
- resolved: 2024-07-23T18:39:37+00:00
- votes: 0
- watchers: 1
- imported: 2025-11-24
Raw content of original issue
Jenkins has a notion of the 'oldest supported remoting version', which amounts to the oldest remoting versions a Jenkins controller is tested against, that's all fair enough.
For those who want to take the risk of using an untested remoting version, the system property hudson.slaves.SlaveComputer.allowUnsupportedRemotingVersions is provided. Which tells the controller to allow agents to connect even if they are using an untested version.
There's a problem however, this code in the remoting https://github.com/jenkinsci/remoting/blob/master/src/main/java/hudson/remoting/Engine.java#L624 unconditionally checks the version the controller said is the minimum supported version, and won't try to make a connection if it is below it (i.e. in reality the controller would accept the request if the agent made it, but it never gets to that point).
Ultimately in my context I have worked around this, by using istio to modify the X-Remoting-Minimum-Version header supplied by the controller in the initial request from agent to controller.
It seems to me that this is a bug, and there should be a way to let agents know to try to use an old version.
- environment:
Issue is present in latest remoting version
Jenkins has a notion of the 'oldest supported remoting version', which amounts to the oldest remoting versions a Jenkins controller is tested against, that's all fair enough.
For those who want to take the risk of using an untested remoting version, the system property hudson.slaves.SlaveComputer.allowUnsupportedRemotingVersions is provided. Which tells the controller to allow agents to connect even if they are using an untested version.
There's a problem however, this code in the remoting https://github.com/jenkinsci/remoting/blob/master/src/main/java/hudson/remoting/Engine.java#L624 unconditionally checks the version the controller said is the minimum supported version, and won't try to make a connection if it is below it (i.e. in reality the controller would accept the request if the agent made it, but it never gets to that point).
Ultimately in my context I have worked around this, by using istio to modify the X-Remoting-Minimum-Version header supplied by the controller in the initial request from agent to controller.
It seems to me that this is a bug, and there should be a way to let agents know to try to use an old version.
Originally reported by thrillpool, imported from: No facility to try unsupported Remoting versions when using inbound agents
Raw content of original issue
Issue is present in latest remoting version