Re:Code that sleeps for a month: Solving durable execution's...
by avianlyric on Friday February 23, 2024 @10:24AM
(#39481680)
The idea of handler sleeping for a month is neat idea. But I do wonder how you test new versions of your code, because it potentially needs to handle months of different historical “paused” states. That’s not something you just write a unit test for, especially as that unit test would only be valid until those states were consumed.
[ Parent
| on HN ]
Re:Code that sleeps for a month: Solving durable execution's...
by pavel_pt on Friday February 23, 2024 @12:21PM
(#39483450)
I think you do it just like you handle compatibility between services – you never remove parameters; you only ever add new optional ones if you have to. This way a message from the past will be compatible with a future handler, same as if you have a caller that depends on you which is using an outdated client/API definition.
But you are right; it's very hard to reason about testing such systems, since you may have accumulated state which causes your handler logic to behave differently. The problem exists in service architectures in general though, it's just very hard to miss with intentionally delayed processing.