Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node seems to squash two msgs together if queried too frequently #13

Open
wsong-fv opened this issue May 29, 2020 · 6 comments · May be fixed by #48
Open

Node seems to squash two msgs together if queried too frequently #13

wsong-fv opened this issue May 29, 2020 · 6 comments · May be fixed by #48
Labels
bug Something isn't working

Comments

@wsong-fv
Copy link

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
Copy link

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

@sxsws
Copy link

sxsws commented Jul 18, 2022

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
Copy link

sys4cad commented Jul 28, 2022

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
Copy link

sys4cad commented Jul 28, 2022

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
Copy link

sys4cad commented Jul 28, 2022

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 )

@rgstephens rgstephens added the bug Something isn't working label Jul 28, 2022
@kyuumeitai kyuumeitai linked a pull request Apr 4, 2023 that will close this issue
@kyuumeitai
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants