Behaviours propagate error details to FragmentResult

[tomaszmichalak]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

{
  "operation": {},
  "response": {
    "transition": "fallback", # FR.transition
    "log": {
      "invocations": [
        {
          "transition": "_error",
          "log": {
            "request": {},
            "response": {}
          },
          "error": {
            "code": "INVALID_STATUS_CODE",
            "message": "Internal Server Error"
          }
        },
        {
          "transition": "_error",
          "log": {
            "request": {},
            "response": {}
          },
          "error": {
            "code": "INVALID_STATUS_CODE",
            "message": "Internal Server Error"
          }
        }
      ],
      "transition": "fallback",
      "log": {}
    }, # result.log
    "error": {
      "code": "INVALID_STATUS_CODE",
      "message": "Internal Server Error"
    }
  }
}

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[marcinus]

1a. Extend ActionInvocationLog with transition and errors
1b. Alternatively, consider putting whole fragmentResult as field instead of doActionLog, transition and errors

2a. Rename success to consideredSuccess
2b. Remove success flag?
2c. Instead of success, create an invokerLog field (as JSON)?

Motivation for 2: it's the behaviour (CB or cache action) who decides whether the invocation was successful or not.
This information should be distinguished from the data pulled from FragmentResult.

[tomaszmichalak]

Please add a comment with the example log.

[marcinus]

Ok, so the current solution (merged to master at this time) is as following:

Invoking an action from another one (called a behaviour) may result in a few different outcomes.

• If action fails in a way that it does not complete (does not deliver FragmentResult), but rather throws an exception (or such an exception is delivered asynchronously), the exception is stored in the error field.
• Otherwise, if action delivers FragmentResult, then it remains its responsibility to populate the information on any errors that occured during processing into this FragmentResult.

Action may use FragmentResult's error field or provide these details in its ActionLog.