|
|
|
|
|
|
by yaj54
732 days ago
|
|
|
ah! this took me a second to grok, but from #2 above: "we just want to send the email service a request that we want to be processed in a month. The thing that hangs around ‘in-flight’ wouldn’t be a journal of a partially-completed workflow, with potentially many steps, but instead a single request message." I'll have to think through how much that solves, but it's a new insight for me - thanks! I like that you're working on this. seems tricky, but figuring out how to clearly write workflows using this pattern could tame a lot of complexity. |
|
|
> Let users write code how they want, its our job to make it work!
> Yes, but it's simply not safe to do this!
I think we need to offer our users a lot of stuff to get it right:
1. Tools so they know when a deploy puts in-flight invocations at risk, or maybe even in their editor, showing what invocations exist at each line of a handler
2. Nudge towards delayed call patterns whereever we can
3. Escape hatches if they absolutely have to change a long-running handler - ways to branch their code on the running version, clever cancellation tricks, 'restart as a new call' operation
Sadly no silver bullet. Delayed calls get you a lot of the way though :p