EEZ Studio Dashboard HTTP: Route Non-Success Responses Through the Error Path

An EEZ Studio Dashboard HTTP request can receive a server response without producing the normal status or result outputs. In the inspected implementation, a non-success HTTP response takes the error route before those ordinary outputs are emitted.

This matters when a Flow waits for status to decide whether a request failed. That design assumes the failure status will arrive on the normal data connector. The HTTP component documentation and the pinned HTTP action implementation should be read together before making that assumption.

The source scope here is EEZ Studio v0.29.0 editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612, using the Dashboard action. It is not a statement about an arbitrary native HTTP library or every later EEZ release.

The response branch precedes ordinary outputs

After awaiting fetch, the action checks response.ok. If that test is false, it calls throwError with a message built from the response status text, falling back to the numeric status converted to text. It does not enter the branch that emits normal status and result values.

The success branch first propagates response.status. It then awaits response.text, propagates the text as result, and finally continues through seqout. That ordering is useful evidence about three different milestones: response classification, body acquisition and ordinary continuation.

An error response body is not read and forwarded through the ordinary result path in this branch. If the server's failure body contains a useful diagnostic object, a downstream JSON parser connected only to result cannot be assumed to receive it.

Give the error route an observable destination

For a diagnostic Dashboard, enable and connect the action's documented error output where appropriate, or use the supported surrounding error-handling design. Make its destination visibly different from the normal result consumer.

Do not reconstruct a machine-readable status contract by parsing an incidental English error string. The implementation prefers statusText when available, so the message is not promised to contain a stable numeric code in every response. An application that needs structured failure metadata should select or implement an interface that explicitly exposes that metadata.

Also distinguish a received non-success response from an exception during fetch or body processing. Both can reach error handling, but they represent different observations. The first has a received response that failed the action's response.ok test. The second may have failed before a response was available, or later while its body was being obtained.

A single red indicator can be acceptable for an operator-facing summary, while the diagnostic record preserves which stage was observed. Do not invent a detailed network cause from the indicator alone.

A successful status is not the finished body

The success branch emits status before awaiting the response text. If body acquisition later throws, the error path can run after a normal status has already been emitted. Therefore, receiving a successful status is not by itself proof that result was delivered or that seqout completed.

This is a particularly useful boundary when designing a request panel. “Response received,” “body available,” and “application accepted the body” are different states. The HTTP action's ordinary seqout follows result propagation, but it still does not validate the server's payload against the product's domain rules.

Keep a previous request's visible result separate from the current request's pending or failed state. If the new request takes the error branch without emitting a result, an application-owned variable or label might still display an old value. This article does not claim that the HTTP action clears that state automatically.

Exercise the branch with a local fixture

Use a disposable local HTTP service with two simple endpoints: one returns a successful status and a distinctive text body; the other returns a non-success status and a different body. No credentials or production services are needed.

Log status, result, seqout and the supported error route as separate observations. Run the success case first, then the failure case without manually clearing the diagnostic display. The second run tests both the branch selection and whether the surrounding UI misleadingly retains the first result.

Add a body-read failure case only if the local fixture and runtime allow it to be created predictably. Keep that case separate from the ordinary non-success response. A connection interruption is not automatically equivalent to a server returning an error status.

No HTTP fixture or Dashboard request was executed for this article. The source establishes a concrete design constraint: failure handling cannot depend solely on a normal status output that this non-success branch does not emit. Build the UI and downstream consumers around the actual branch contract, and record any richer failure information through an interface that explicitly provides it.