Hacker News Reader

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.

View on HN

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.

Yeah, in my view only an 'intent' eg a request, or event in queue, or a line in a DB, should span that kind of time. Then you just version that intent

Reply on news.ycombinator.com