# We have http-request, tcp-request, serial-request - any objections to an mqtt-request?

**URL:** <https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413>\
**Category:** Feature Requests\
**Created:** [5 July 2026 19:45 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413 "2026-07-05T19:45:39Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 09:20 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/21 "2026-07-06T09:20:23Z")

</div>

> [@gregorius](#):
>
> From [here](https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern):
> 
> > It’s important to note that this data is not relevant to the MQTT broker but serves to identify the relationship between sender and receiver.
> 
> So the client is still responsible for matching the original request with the response using the extra `correlationData` field in MQTTv5. So the client has to maintain the state while the broker remains stateless.
> 
> So then the new mqtt node here needs to know how to match request/response pairs using `correlationData` - I assume this would be a "simple" look up in a lookup table somewhere.

Exactly. Nailed it.

The MQTT broker remains a pure, stateless postman. It doesn't care about the relationship between the packets - it just routes the request to the backend and the response back to Node-RED.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [6 July 2026 09:36 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/22 "2026-07-06T09:36:04Z")

</div>

> [@Steve-Mcl](#):
>
> it just routes the request to the backend and the response back to Node-RED.

Ok so the mqtt-request node only differs from the http-request and tcp-request nodes in that it will have state and maintain a lookup table with all the requests that have been sent. There could be a risk of memory exhaustion if too many unanswered requests are sent. Are you going to add a limit on the memory consumption? Or use something like a [circular buffer](https://en.wikipedia.org/wiki/Circular_buffer) to ensure that NR doesn't crash if a third party server goes down and doesn't respond?

I would hide the `correlationData` - i.e. the mqtt-request node should always manage that. After all, I as a user of the node don't want to be bothered with setting it if the node matches on the response for me anyway. For me it's a bit like the `res`/`req` msg attributes for http nodes - I won't want to be setting them, they're managed for me.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 10:29 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/23 "2026-07-06T10:29:51Z")

</div>

> [@gregorius](#):
>
> it will have state and maintain a lookup table with all the requests that have been sent. There could be a risk of memory exhaustion if too many unanswered requests are sent.

Yeah, point was raised by Dave yesterday:

> [@Steve-Mcl](#):
>
> > [@dceejay](#):
> >
> > came up recently (which is why I remembered) over here - [Help with `delay` node set to `rate limit` - #16 by dceejay](https://discourse.nodered.org/t/help-with-delay-node-set-to-rate-limit/101400/16)
> 
> Thanks Dave. That lead me straight to it - I updated code late last night but didnt get around to posting back that I added support for `nodeMessageBufferMaxLength` until now:
> 
> ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/3/1/31418bbce2e1d2919388ddb077a920ac91262509.png)

It is the same mechanism other core nodes employ so I am happy it was flagged.

**[edit]**

To add to that, there is a hard requirement for a timeout value greater than zero (tho currently no upper limit). That timeout clears the items from the map as they expire (self healing). It can still be problematic faced with a flurry of requests obviously but that is now somewhat contained by the `nodeMessageBufferMaxLength`

  

> [@gregorius](#):
>
> I would hide the `correlationData`

That was actually how I designed it initially! 👊

However, while auto-generating a hidden UUID works perfectly for a closed ecosystem where Node-RED talks to (for example) another Node-RED instance, `correlationData` in the MQTT v5 spec can be a UTF-8 string _or_ raw binary data. I have read as much as I can stand to determine if I should or should not show or hide this field. The main reason I decided to show it was thinking of the likes of low powered devices (like PLCs) where the `correlationData` might be utelised as a register ID, or a composite value with meaning, or an index number for sequential operations, etc. I also remember reading something about specific requirements for OpenTelemetry (I may have been hallucinating at that point).

In the end, I just bit the bullet and decided to show it but make it _opinionated by default, with user override possible_. By default, it will automatically handle everything via an auto-generated unique ID

Thanks for the tasking questions tho - it helps me determine if right choices were made.

It does also make me think that perhaps a collapsed "Advance Options" panel might be preferable (to keep the edit panel light)

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [6 July 2026 10:40 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/24 "2026-07-06T10:40:26Z")

</div>

> [@Steve-Mcl](#):
>
> a collapsed "Advance Options" panel might be

Yer that might be a good comprise. I would assume that if the `correlationData` has meaning, then the user will probably end up creating a custom solution using the existing MQTT node anyway.

More and more, I've tended to less and less - i.e. less is more principle, hence I would remove the field and see if there are requests to actually have the field come in and what the use case could be.

But I'm not target audience! For me the correlationData is like a session id inside a cookie: I just want the session, I don't care about the session id or the how the association to session is made.

> [@Steve-Mcl](#):
>
> Thanks for the tasking questions tho -

Thanks for the explanation and you've convinced me, it definitely sounds like a core feature.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 July 2026 10:56 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/25 "2026-07-06T10:56:25Z")

</div>

Does the node queue requests and wait for the previous one to complete before sending the next one or can there be multiple transactions underway at once? If the latter then how will the requesting client match responses to requests?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 11:04 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/26 "2026-07-06T11:04:05Z")

</div>

> [@Colin](#):
>
> Does the node queue requests and wait for the previous one to complete before sending the nex

Multiple transactions can be underway simultaneously. The node does not block unless the limit is hit.

> [@Colin](#):
>
> If the latter then how will the requesting client match responses to requests?

It relies on the internal lookup map.

When a request is sent, the node stores the original `msg` reference in memory using the unique `correlationData` as the key (along with a node identifier). When a response arrives, the node looks up that incoming `correlationData` key, grabs the matching `msg`, and passes it out of the respective node.

Because every concurrent request gets its own unique correlation ID (auto-generated as a UUID by default), multiple in-flight requests can happily coexist without overlapping or blocking each other.

Note, this map is per-broker (if you have such as situation, they can never collide due to protocol wire separation)

[EDIT]  
Forgot to add - collisions are detected up front (before publish). If a correlation value is ALREADY in-flight, that message is rejected. Yes, this is opinionated, but feels like the right fit.  
In short, one could re-use the same correlation data over and over BUT they would need to ensure the last request was resolved BEFORE they pushed that same correlation message again. That is user choice.

Not sure if that is 100% clear - feel free to say "what are you talkin about willis!" 😉

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [6 July 2026 11:13 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/27 "2026-07-06T11:13:07Z")

</div>

> [@Steve-Mcl](#):
>
> re-use the same correlation data over and over

This might seem unlikely but similar to the hidden `_msgid` field that is often the same because messages are just recycled. Anything that uses a split might well have several messages with the same `correlationData` value if the user is setting them via the msg.

On the other hand, it's a good way to prevent duplicate requests from being sent, no one wants to turn on their lights twice when they're already on 😉

_Caveat Emptor_ I would say.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 July 2026 11:25 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/28 "2026-07-06T11:25:02Z")

</div>

How does the _client flow_ match a response to the the request? If the flow sends in multiple requests, the responses could presumably appear in a different order.

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [6 July 2026 11:27 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/29 "2026-07-06T11:27:06Z")

</div>

> [@Steve-Mcl](#):
>
> once you know you need this - you need it bad

I maintain the Snap! MQTT Library and one user has a great need for request/response so its been added in 🙂

It is implemented using MQTT3.1 - it'll be interesting to see if it is compatible with this implementation

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 12:08 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/30 "2026-07-06T12:08:50Z")

</div>

> [@Colin](#):
>
> How does the _client flow_ match a response to the the request? If the flow sends in multiple requests, the responses could presumably appear in a different order

At the other end (the other client) will receive the topic, the response topic, correlation data (and other properties). They route this message accordingly based on whatever their desire (topic, payload content, correlation data value, user properties), then post the result back to the topic specified in response topic AND, importantly, include the original correlation data value. This way it doesn't matter if messages are handled out of order.

At the mqtt request side (originator), it is completely seamless. You push your message in and the associated response is automatically taken from the map and emitted out of the node.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [6 July 2026 12:22 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/31 "2026-07-06T12:22:11Z")

</div>

Hmm, just like a REAL message queue service! 😉

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 July 2026 12:28 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/32 "2026-07-06T12:28:36Z")

</div>

> [@Steve-Mcl](#):
>
> At the mqtt request side (originator), it is completely seamless. You push your message in and the associated response is automatically taken from the map and emitted out of the node.

So if I send in, say, three requests, then the responses (or timeout errors) will appear in the same order, even though that may mean that the node has to delay later responses until earlier ones have completed or timed out.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 12:50 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/33 "2026-07-06T12:50:44Z")

</div>

No, sorry if i am being unclear. It is not a stack. The map means responses (as they arrive - in order / out of order) are taken from the map and emitted out of the MQTT Request node as they land.

If your 1st message takes 6 seconds, 2nd message takes 4 and the 3rd message takes 2 seconds, they will be output in reverse order - immediately upon reception back at the requestor.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 July 2026 13:01 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/34 "2026-07-06T13:01:20Z")

</div>

So if there is a timeout, is there any way of knowing which message has not got through, other than providing my own correlation data? Or queuing the messages externally and passing them to the request node one at a time.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 13:10 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/35 "2026-07-06T13:10:33Z")

</div>

The node will throw and you catch it and can get the topic (and other data) that you can identify the original message. But it does give me pause for thought. I will run some scenarios through my head.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 July 2026 13:17 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/36 "2026-07-06T13:17:18Z")

</div>

In fact I realise that it isn't an issue for my particular use case, which is guaranteed delivery of MQTT messages to an end client, as I will use @colinl/node-red-guaranteed-delivery, which queues the messages and releases them one at a time, so the new node will only ever be handling one message at a time.

Presumably, if a message times out, but later a response is received from the end client, that will just be silently ignored. Similarly if two responses are seen with the same correlation data the second one will be ignored.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 13:26 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/37 "2026-07-06T13:26:07Z")

</div>

> [@Colin](#):
>
> Presumably, if a message times out, but later a response is received from the end client, that will just be silently ignored. Similarly if two responses are seen with the same correlation data the second one will be ignored.

Correct and correct. Once "spent", it is not available to output a 2nd time.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 July 2026 13:41 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/38 "2026-07-06T13:41:20Z")

</div>

One other detail, if a valid response is seen then the node will send that, and trigger any Complete node attached, and if there is a timeout then it will trigger a Catch node and not send a message?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [6 July 2026 13:51 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/39 "2026-07-06T13:51:27Z")

</div>

That is the intent (catch for sure) but I will need to double check the `done` (`complete` node signaller) calls when i get back into it - thanks for all the clarifying questions guys.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [6 July 2026 16:05 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/40 "2026-07-06T16:05:16Z")

</div>

Great thanks.

Will there be a way of testing it before it is released?

[Previous page](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413.md?page=1)

[Next page](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413.md?page=3)