HTTP transport failures are mapped to communication/422 instead of appropriate status codes

[gmunozfe]

What happened:

HTTP call tasks currently map ProcessingException failures to a communication WorkflowError using Errors.DATA.status(), which results in status 422.

For example, the following failures are currently exposed as communication/422:

• HTTP read timeout
  • ProcessingException
  • caused by a timeout exception
• TCP reset / proxy connection loss
  • ProcessingException
  • caused by java.io.IOException: Connection was closed

Example response:

{
  "type": "https://serverlessworkflow.io/spec/1.0.0/errors/communication",
  "status": 422,
  "instance": "do/0/callUnstableService",
  "title": "java.io.IOException: Connection was closed",
  "detail": null
}

What you expected to happen:

Transport-level failures should not be reported as 422 Unprocessable Content.

Mapping could be:

• HTTP read timeout → communication / 408

• TCP reset / connection loss (IOException) → communication / 500

How to reproduce it:

Execute a workflow containing an HTTP call:

document:
dsl: '1.0.0'
namespace: qe
name: network-chaos
version: '1.0.0'

do:

• callUnstableService:
  call: http
  with:
  method: get
  endpoint: ${ .endpoint }

Configure a short HTTP client read timeout and invoke an endpoint that does not respond before that timeout.

Anything else we need to know?:

The WebApplicationException path already preserves the HTTP status correctly.