Node seems to squash two msgs together if queried too frequently

[wsong-fv]

I am using this node along with the node-red-node-email module. I have found that when I query the graphql endpoint too frequently (ie two requests one after another), the graphql node returns two msgs, one for each query, but the _msgid and all the other properties apart from payload are identical to the second query message object.

Anticipated behavior: Two distinct message objects should be returned.

Actual behavior: Two identical message objects are returned, with only the contents of the payload different.

Minimal steps to replicate behavior: Pass two Message objects containing query parameters one right after another, ensure that the two Message objects have fields with distinct values. Observe that the two returned messages will be identical to one of the Message objects passed in.

[fhsevenbel]

As a workaround, you can use the built in delay node to generate a rate limit with lets say 1 message per second

[sxsws]

This has taken hours to diagnose for me! This node is certainly merging messages together, overwriting other properties of the message with the last one.

I'm going to guess there needs to be some kind of message buffer / queue that stores incoming messages whilst waiting for responses?

[sys4cad]

this node mess up http request & reply pair. :(
If incoming is faster than graphql processing.. then response node will reply with other incoming req.
this means user can see other's account content if bank detail service implemented by http-req>graphgl > http-reply.... :(

[sys4cad]

As a workaround, you can use the built in delay node to generate a rate limit with lets say 1 message per second

this doesn't work if graphql takes more than 1 sec per msg.

[sys4cad]

I am using this node along with the node-red-node-email module. I have found that when I query the graphql endpoint too frequently (ie two requests one after another), the graphql node returns two msgs, one for each query, but the _msgid and all the other properties apart from payload are identical to the second query message object.

Anticipated behavior: Two distinct message objects should be returned.

Actual behavior: Two identical message objects are returned, with only the contents of the payload different.

Minimal steps to replicate behavior: Pass two Message objects containing query parameters one right after another, ensure that the two Message objects have fields with distinct values. Observe that the two returned messages will be identical to one of the Message objects passed in.

ANS1: you can split multiple messages and call parallel graphql ,then merge into array output as long as each graphql can handle one message properly
ANS2: use simple queue and call graphql by iteration ( CONS: performance degrade )

[kyuumeitai]

I was having this issue so I created a pull request. Basically I deep cloned the msg instead of referencing it. There was another issue with some non initialized object.

Hope this pull request helps!