-
Notifications
You must be signed in to change notification settings - Fork 185
Conversation
/assign roycaihw |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: fabxc If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Raise an ApiException for error events that indicate a watch failure despite the HTTP response indicating success. Fixes kubernetes-client#57 Signed-off-by: Fabian Reinartz <freinartz@google.com>
Codecov Report
@@ Coverage Diff @@
## master #102 +/- ##
==========================================
+ Coverage 92.04% 92.12% +0.07%
==========================================
Files 13 13
Lines 1182 1206 +24
==========================================
+ Hits 1088 1111 +23
- Misses 94 95 +1
Continue to review full report at Codecov.
|
Should we really throw an exception here and not just retry the watch? |
On a better look, I do not think this fully addresses #57 in any case. To me
So, I think: this should be handled sooner, and it should just automatically resume if possible. |
I made slightly improved (in my view) version here: master...mitar:retry-watch Would you maybe be interested in incorporating those changes here and updating tests here to trigger those other conditions as well? For example, I am using |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Raise an ApiException for error events that indicate a watch failure
despite the HTTP response indicating success.
Fixes #57
The ApiException constructor indicates that it's intended to be used manually as well. Thus it seemed convenient to use and is the least likely to break any callers that likely have handling for that exception in place already.
@roycaihw