[PR] Refactoring 4/3: In-memory handler outcomes & persistent state merges

[kopf-archiver]

A pull request by nolar at 2019-11-06 14:40:04+00:00
Original URL: zalando-incubator/kopf#221
Merged by nolar at 2019-11-08 14:30:24+00:00

Code refactoring (part 4 of 3): split reactor state to handlers' outcomes and actual state persistence.

Issue : preparation for #59 #187 #142
Preceded: #209 (part 1/3), #210 (part 2/3), #211 (part 3/3).

Description

Having terminology fixed in #209 and the "state" word released for the reactor's state persistence, we now improve the state management itself.

The purpose is to separate the state persistence in the object's status stenza from the handler's outcomes. Specifically, to make it possible to keep the state of the handlers that are not resource-related — e.g. activity handlers, which are handled completely in-memory.

For this, a new entity is introduced: an outcome, which is conceptually close to asyncio/threading futures (result+exception bundled), but have handler-specific aspects: delays, temporary or permanent errors, etc.

The state persistence is then refactored to include the math of merging the existent state with the new outcomes, and persisting the new resulting state back to the objects.

The resource-specific state persistence is then moved upward in the call stack: from the generic handlers, to the resource-specific handling. The generic handlers now return the in-memory outcomes only, and persist nothing.

See the list of commit with step-by-step explanation of changes.

Types of Changes

• Refactor/improvements

---

Commented by ancelotpinto at 2019-11-08 09:23:47+00:00
 

lgtm