Initial scoping for happy/non-happy path and other such control mechanisms - beware of the rabbit hole

[frankkilcommins]

What is the general feeling for how deep we want to go with respect to handling error scenarios/conditions in the workflows? I somewhat weary in us trying to deliver a BPM type sledge hammer approach to describing the expected value flows of an API.

Nevertheless, there should be some discussion and consensus on how far workflows will go.

Some options to start discussion:

• Indicate workflow will stop upon error (e.g. managed/expected failure) and can be picked up from point of failure
• Indicate entire workflow will be retried
• Indicate the workflow (or transaction) will be rolled back upon failure

[swaldron58]

Why the specific use case such as an error path? Why not behaviors required such as the need for a workflow to self abort, to be stopped (canceled), to be paused and resumed, and to be rolled back. On the latter I'd prefer a recovery workflow defined. "roll back" implies status kept somewhere and a commit ,,, please not that again. Do we set as a prerequisite workflows like the APIs they support be stateless. Anyway, the point being to consider defining behaviors needed to meet needs such as error paths but many others.

[frankkilcommins]

Agree that the scoping discussion is broader than just error paths. I've updated the discussion title to hopefully reflect that.