Service Task Retry Logic

[calexh-sar]

From Slack post: We've been talking a lot about how best to do retries on service tasks. We could certainly build out retry logic using existing tools, but also have a strong sense that doing that over and over will quickly become cumbersome, unreadable, and difficult to maintain.

We're very interested to hear what your thoughts are on how to approach this. A couple possibilities for a new feature:

• Offering simple/standard retry features in a manner that's similar to designating serial or parallel multiplexing: have a special icon for retry and some smallish set of standard features so that retry logic can be applied to a service task without creating new nodes
• Thinking along the lines of how a Python decorator takes a callable as an argument, it could be cool to build a bespoke retry process that could function as a wrapper around a passed-in service task.
• Or, perhaps, how hard would it be to allow a connector proxy to schedule itself to run again at an arbitrary point in the future? If we could push a re-run into the queue, then all our retry logic could be written in Python instead of BPMN. Would it break anything if a service task blocked as long as a manual task might?

[burnettk]

dylan is going to check to see if the existing get request v2 retry count parameter is sufficient for their use cases.