Message Reply New in 1.0.8
Sends the answer back to whoever made the request that started this run through Message In — a Message Out in request mode, a screen’s Send message that waits for a reply, or a script’s request. It answers with the payload, or with an error.
Type: message-reply · Category: Message Bus · Ports: one input · one output
When to use it
- Ending a request/response pipeline, success and failure alike
- Turning a caught failure into an error the requester can read
Settings
| Setting | Key | Default | Purpose |
|---|---|---|---|
| Reply with | status | ok | OK — send msg.payload back, or Error — reject the request. |
| Error message | errorMessage | — | Error only. Empty: the message of the error a Catch caught, or request rejected. |
If the sender did a plain send rather than a request, there is nobody to answer: the node passes the message through and does nothing. In a run that Message In did not start, it fails.
Example — a lookup that says what went wrong
Message In (recipe.lookup) → SQL (select recipe) → Message Reply (OK)
Catch (all nodes) → Message Reply (Error)
Fed by a Catch, an error reply carries the caught error's message and where it happened — the error details and the failed node's id, type and name — so the requester learns what failed, not just that something did. The failed node's input is left out: it is this pipeline's data, not the requester's.
Gotchas
- A run that ends without replying is answered for you. When a request's run finishes without reaching Message Reply — a Switch dropped it, a node failed with nothing catching it — the requester gets an error at once saying so (the receiving pipeline finished without replying, or the receiving pipeline failed: …) instead of waiting out its timeout. A pipeline that contains a Timer is the exception: a deferred branch may still reply later.
- The first reply wins. If two Message In pipelines answer the same request, the requester takes whichever arrives first. Use a load-sharing group when only one should handle it.