Skip to content
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

[PR] Distinguish "no handlers at all" and "no handers for now" cases #285

Closed
5 tasks done
kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Closed
5 tasks done
Labels
archive bug Something isn't working

Comments

@kopf-archiver
Copy link

kopf-archiver bot commented Aug 18, 2020

A pull request by nolar at 2020-01-03 13:46:21+00:00
Original URL: zalando-incubator/kopf#285
Merged by nolar at 2020-01-08 10:41:39+00:00

What do these changes do?

Fixes an issue with time discrepancies that stopped the reaction cycle if the operator was unlucky enough to hit the scheduled awakening time with 1ms precision.

Description

Previously, "now" of handler.awakened and "now" of state.delay were different (maybe for less than 1 ms). If the scheduled awakening time was unlucky to be between these two points in time, the operator stopped reacting on this object until any other events or changes arrive.

Specifically, the operator neither selected the handlers to be executed (because it was "1ms too early" for the handler.awakened), nor did it sleep (because it was "1ms too late" in the state.delay property) — with the same value of delayed field, just the code being executed exactly during this awakening time.

Due to how zero-time delay is treated (i.e. same as None — no sleep at all), the dummy patch was not applied to trigger the next steps of the reaction cycle.

After the fix, 0-delay and None-delay are treated differently: the zero-time delay does not sleep, but produces a dummy patch to trigger the reaction cycle after the sleep is over (as if it was an actual zero-time sleep). The None delay does not do any sleeping or dummy patching.

This eliminates the problem with the "now" time inconsistencies, while keeps the multiple datetime.datetime.utcnow() possible — to properly calculate the needed sleep time without the code overhead included.

The change does not affect the users directly. The probability of hitting this issue was low anyway.

Issues/PRs

Issues: closes #284

Type of changes

  • Bug fix (non-breaking change which fixes an issue)

Checklist

  • The code addresses only the mentioned problem, and this problem only
  • I think the code is well written
  • Unit tests for the changes exist
  • Documentation reflects the changes
  • If you provide code modification, please add yourself to CONTRIBUTORS.txt
@kopf-archiver kopf-archiver bot closed this as completed Aug 18, 2020
@kopf-archiver kopf-archiver bot changed the title [archival placeholder] [PR] Distinguish "no handlers at all" and "no handers for now" cases Aug 19, 2020
@kopf-archiver kopf-archiver bot added the bug Something isn't working label Aug 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
archive bug Something isn't working
Projects
None yet
Development

No branches or pull requests

0 participants