-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Friendlier handling of DeploymentHandshakeException
from CLI in -webSocket
mode
#9591
Conversation
/label ready-for-merge This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback. Thanks! |
@jglick I have been seeing this test flake on Windows ever since this PR was merged: https://ci.jenkins.io/job/Core/job/jenkins/job/master/6468/ The latest build has the same flake: https://ci.jenkins.io/job/Core/job/jenkins/job/master/6479/ Can you please look at this before tomorrow's weekly to release to ensure that this flaky test doesn't hold up the release? |
FYI I can actually reproduce the failure on my Linux system, but not every time. Sometimes the new test passes, and sometimes the new test fails. |
I disabled the test in #9687 to avoid disrupting tomorrow's weekly release. |
I can't quite tell if this PR has any negative effects on the production code or not, so I just disabled the test. But if there are negative effects on the production code, we might want to revert the non-test changes in this PR as well. |
I think the NPE is just something that would have confused the error reporting on a failed request to begin with, though I never tracked down the root bug in Tyrus. |
If the CLI client gets as far as authenticating the connection and establishing the WebSocket upgrade, then the remaining error handling is fairly well defined
jenkins/core/src/main/java/hudson/cli/CLICommand.java
Lines 223 to 237 in 48f7a0c
-http
mode either, but as of #7605 that is not used by default.)Originally noticed in the context of a proprietary plugin sending a 401 response under certain circumstances, but in fact seems applicable also to the more mundane scenaio of a mistyped API token.
Note that the response body is not exposed by the Tyrus client (even importing implementation classes), so this cannot be displayed, only the status code and headers. I actually prototyped a rewrite to the JDK’s built-in WebSocket client, which offers access to the response, but the body is still empty. (It may be a good idea to do this rewrite anyway, to avoid an external dep and bloat in
jenkins-cli.jar
.)Testing done
Without patch:
With:
Proposed changelog entries
-webSocket
mode.Before the changes are marked as
ready-for-merge
:Maintainer checklist