[REST connector] Access response in error expression with status code 400

[saig0]

Is your feature request related to a problem? Please describe.

I use the SpaceTraders connector in my process and try to access the response in the error expression. The connector is based on Camunda's REST connector.

I followed the documentation for error expressions (ref) but I can't access the response if the API returned a status code 400.

In my case, the API returns a status code 400 and sends additional data about the failure:

// status code
400 Bad Request

// URL
POST https://api.spacetraders.io/v2/my/ships/C_4979-1/navigate

// response data
{
   "error":{
      "message":"Ship action failed. Ship is not currently in orbit at X1-ZQ60-A1.",
      "code":4236,
      "data":{
         "waypointSymbol":"X1-ZQ60-A1"
      }
   }
}

NOTE: This is specific for a failure response (i.e. status code 4xx). If the response returns successfully (i.e. status code 2xx), I can access the response data in the error expression.

Describe the solution you'd like

I can access the response data in the error expression, even if the response has a status code 400.

I can use the following error expression to throw a BPMN error if the error code in the response matches:

if matches(error.code, "4\d\d") and response.body.error.code = 4236 
then bpmnError("shipNotInOrbitError", response.body.error.message, response.body.error.data)
else null

Describe alternatives you've considered

None. Since the response has a status code 400, I can't handle the response in the connector or the process.

Additional context

How to reproduce:

1. Deploy the process Handle BPMN error.bpmn (with .bpmn file extension)
2. Create a new instance of the process
3. Wait and verify that the process instance has an incident at the last task

[johnBgood]

@saig0 Thank you for reporting this.
Something we can do short term is provide the response (if any) in the error.errorVariables object.

You would then be able to use the following error expression:

if matches(error.code, "4\d\d") and error.errorVariables.response.error.code = 4236 
then bpmnError("shipNotInOrbitError", error.errorVariables.response.error.message, error.errorVariables.response.error.data)
else null

[sbuettner]

@johnBgood Can we change the property name to variables to not repeat the error prefix here?

[johnBgood]

@sbuettner It's not been release if I'm correct, so yes let's change the name 👍

[saig0]

@johnBgood sounds interesting. 👍

Why do we plan to store the response in error.variables.response.x instead of response.body.x?

In other cases, I can access the response directly via response.body.x. Using a different prefix error.variables.response.x could be more complicated and confusing for users.

[johnBgood]

@saig0 good question :D

The idea is that the solution explained above is pretty much free to implement + it solves the user need.

Then, we can collect users' feedback, if they're happy great. If not we can iterate and go for the more complex solution.
Using response.body.x is more complex and it would require some specific code both in the Webhook Connector and the ConnectorJobHandler which is the core piece for Outbound Connectors.

It's possible but longer and trickier :) (but we might implement it some day)

[saig0]

@johnBgood thank you for the reasoning. 👍

I care about the UX and vote for an intuitive solution that is aligned with the other expressions. If it is a general behavior that connectors store the error details in error.variables, it's fine.

I don't need a solution very soon. 😉

[b3rnh8rd]

Is there already a plan for when this feature will be available? Our project uses the REST connectors quite frequently. In many cases, the response would also be essential for correct processing in the event of an error.