Ignore "404 Not Found" when patching after deletion during handling #160
Conversation
🤖 zincr found 0 problems , 0 warnings |
🤖 zincr found 1 problem , 0 warningsDetails on how to resolve are provided below ApprovalsAll proposed changes must be reviewed by project maintainers before they can be merged Not enough people have approved this pull request - please ensure that 1 additional user, who have not contributed to this pull request approve the changes.
|
| await loop.run_in_executor(config.WorkersConfig.get_syn_executor(), obj.patch, patch) | ||
| except pykube.ObjectDoesNotExist: | ||
| pass | ||
| except requests.exceptions.HTTPError as e: |
There was a problem hiding this comment.
can you explain in what circumstances this exception might raise?
There was a problem hiding this comment.
Indeed! Good that you've noticed that.
Pykube has its own handling of all exceptions, and overrides it with its own pykube.HTTPError only if they are applicaton/json and its json has kind=="Status" — regardless of the status code. I don't know how reliable this condition is, so it might happen that the requests's exceptions leak out.
But that pykube's exception should be caught too, same as in the auth.py (on verification).
And, unlike the GET-methods in fetching.py, pykube.ObjectDoesNotExist will not be raised in PATCH/POST/PUT-methods. But that might change in the future, so we at least expect it (for forward-compatibility).
There was a problem hiding this comment.
Fixed with a new commit.
There was a problem hiding this comment.
Right, being more conservative in there regards shouldn't hurt
Codecov Report
@@ Coverage Diff @@
## master #160 +/- ##
==========================================
- Coverage 82.76% 81.23% -1.54%
==========================================
Files 32 32
Lines 1596 1652 +56
Branches 231 241 +10
==========================================
+ Hits 1321 1342 +21
- Misses 230 262 +32
- Partials 45 48 +3
|
Finalizer will address an issue with cleanup when the operator is down during deletion Catch some notFound exections when deleting gone vSphere objects Upgrade to kopf v0.22 to avoid [404s](zalando-incubator/kopf#160)
Ignore errors when patching an object that was removed too quickly, during the handling cycle or inside of the handlers.
Description
If a handler deletes the object being handled, Kopf will try to patch its status after the handler as usually, and will fail, since the object does not exist anymore.
The same happens if the object is deleted too quickly, while the handler is running.
Previously, this was prevented by always having a finalizer before any handling. Since #24, the finalizer is added only when there are non-optional delete handlers, and skipped otherwise. So, it is now possible that the object is deleted while we handling it.
Types of Changes
Review