Recommended actor versioning pattern
What is the recommended pattern for handling actor's code and state mismatch after releasing a new version of my app (the new code produces different state)? If I understand correctly the state is always persisted, but the code that interacts with the state can change when actor upgrades it's version. Is doing a state migration onWake the correct solution here?
For my usecase I don't really need actor's state - I could just use vars, because the data will be persisted into a separate database. Doing this would keep the "state"<->code in sync after a release, but it looks like a total antipattern.
I'm totally new to actors and DOs, so I'm sorry if I'm missing something totally obvious. I need some guidance on this issue 🙏
6 Replies
Very interesting question indeed! @Nathan I think this topic would be great to cover in our docs!
hey! i’ll get back to you tomorrow on this. we do need a docs page for this.
Hi @Nathan any updates on this? I also wanted to ask what is your preferred communication channel, I just have some general product questions. I want to go through with rivet for the app that we are building.
hey! i apologize, we’ve been wrapped up with the holidays. discord is best.
i want to write a bit more in depth, but for now — the tldr is either:
- for simple state use cases, make new properties optional OR use
c.state = { defaultProp: whatever, …c.state } in onWake to set default props so you don’t need options
- for more complex state, store a version number and use onWake to upgrade the state version on wake
i’ll explain a bit better tomorrow
feel free to shoot any other questions tooI hit you up with a DM about the cloud offering, but I also have another question related to long running actions. In the fan-in fan-out patter https://www.rivet.dev/docs/actors/design-patterns/#fan-in-and-fan-out if the worker is reset after crash while performing some action, will the action itself be rerun? There is also a 2nd edgecase (not sure how probable) where main actor goes down and is unable to collect the result. How would you recommend to handle these edgecases? My idea is to check a flag stored in state and vars, if the flag is missing from vars and it's present in the state the worker has restarted, so we manually schedule the action immediately.
if the worker is reset after crash while performing some action, will the action itself be rerun?We have this implemented, but the default behavior is no. Can you explain your pattern a bit better (dms are fine too) to make sure I'm recommending the right approach?
where main actor goes down and is unable to collect the result. How would you recommend to handle these edgecases?Sounds like this is similar to what you're recommending – the fan-out actors should retry sending the result until success using something like promise-retry (https://www.npmjs.com/package/promise-retry?activeTab=readme) Related – you can use
onWake to detect if an actor starts again so you don't have to a vars hack
On the roadmap – we'll have something called an "inbox" which is a queue you can write to for each actor even if the actor itself is crashed or overloaded.
Do you need more details on the versioning approach I mentioned?