Allow mapping of client-side disconnects during response streaming to 4xx status codes (instead of 500)

Problem description:

Currently, in IBM API Connect, if a client application disconnects or times out while the API Gateway is actively streaming a successful backend response (e.g., a 200 OK), the gateway attempts to write to the closed client socket and fails. It then logs the error "Failed to use data streaming to send the response payload" and records the transaction as a 500 Internal Server Error in API Analytics.

The limitation:

Because this disconnection occurs during the direct response writing phase—after the policy execution flow (including post-flow) has finished—there is no policy-level variable, error condition, or context attribute exposed. Consequently, there is no supported way to use GatewayScript, Global Error Policies, or catch blocks to distinguish this specific client-initiated disconnect from a genuine gateway or backend server failure.

Business & operational impact:

Treating client-side disconnects as 500 Internal Server Errors causes significant operational friction:

• False monitoring alerts: It floods API analytics and dashboards with 500 errors, making healthy APIs appear unstable.

• Wasted support effort: It triggers critical server-side alerts, forcing support teams to investigate the gateway and backend for infrastructure failures, only to discover the fault lies entirely with the client application.

• Skewed metrics: It makes it impossible to accurately distinguish between infrastructure health issues and client behavioral issues in our SLAs.

Requested feature:

We request a product enhancement to expose a signal, condition, or native configuration setting that allows the Gateway and Analytics to distinguish a client-initiated disconnect from an actual server-side write failure. Specifically, we need a supported mechanism to categorize these specific socket write errors as client warnings (e.g., mapping them to a 499 Client Closed Request or similar 4xx status code) rather than defaulting to a 500 Internal Server Error.

Attached the simple pictorial representation of the flow for the reference.