| Thanks a lot for reading the post and reaching our with questions! > That's great. Is it persisted to retry even after a reboot? Absolutely! Our scheduler service manages the state on behalf of the application, even if the program restarts, the operation persists until completion. > What informs the end user, in interactive situations, and what does it tell them? Since the Dispatch SDK integrates directly in the code of the application, it's compatible with typical system observability tools. Say you're using metrics or traces to track operations, you can emit this telemetry on your dispatch functions. That being said, we know how important it is to have a built-in solution for this! > What if the operation is delayed so much that it no longer makes sense; can we cancel it? Different ways to solve this, one is to simply raise a permanent error so the operation stops, but in some cases it makes more sense for the system to expose controls so the operator can act on group of similar operations for example. Those are features on our roadmap at this time, but definitely agree on the importance! > How do we identify a particular one, out of thousands going through the same function: by some of the arguments, like in memoization? Searching through the state or history of the systems is also a key feature that a platform like Dispatch needs to provide to be "complete". We're still in early development so we haven't gotten to add this feature yet, but definitely excited to delivering it! |