-
-
Notifications
You must be signed in to change notification settings - Fork 121
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
Possible bug with messages #95
Comments
I was incorrect, it was due to a bug with another interconnected component down the chain that I created. Spent some more time looking into it today and figured it out. |
Just a note that the reason the other component ended up having a bug was because the message id does not seem to get set which is something I depended on assuming that it would always be set and always be unique (created during the newmessage() call) but that doesn't appear to be the case. I am seeing it undefined and even if I create a message then set msg.id = GUID() before sending the message the message id still appears undefined in when examined from the next component.
Because With these details, I'll re-open the ticket and leave it up to you to determine if this is a bug... a lack of documentation explaining id reasoning for being undefined or something else. |
@ColtonMcInroy You should not expect to have |
@Will-create According to the documentation...
If this is no longer correct or some details in regards to this are missing could you update the documentation? |
@ColtonMcInroy Yes, documentation should be updated. I thank you. Thanks alot |
I have been troubleshooting a bug for the past bit now and not sure if it is an issue with Flow, Total4, or my own code.
I have a Code component with two outputs (I'm actually using the Multiplexer version of the Code component so I can use named outputs). I'm using it to handle an aspect to GraphQL resolver processing for some context. Here is the code in the component...
When a message comes into this component it parses the data converting true/false values recursively into functions. The function is then used by a GraphQL engine (Envelop) to be executed. When the GraphQL engine goes to execute the resolver functions it will end up running the above promise which creates a new message and upon that message ending returns the data as the resolved response.
This actually works fine for any requests that process synchronously but it appears that when multiple resolvers execute at the same time in parallel rather than series a bug appears. I have done some tracking down to see if I could find the cause in my code, but thus far have been unable to blame it on myself or the Envelop GraphQL engine.
So the problem that occurs is when the resolvers execute, when it is just in series they execute perfectly fine. When there are any parallel resolvers executed the message processing appears to become conflicted and responds incorrectly.
Here is an example...
This is some debug output that I produced to see what is going on. This is a successful execution of the query...
To explain the debug output when "Waiting on Execute" occurs the GraphQL engine runs and starts executing the resolvers. The code from the above component executes and outputs the lines starting with "Resolver" and "Resolved" showing what resolver it is trying to run and then the response of that resolver. The response of the resolver is obtained from the msg.on('end',...) call executing resolve().
Now the problems occurs when you do anything that causes parallel execution of resolvers... for example...
This is where things mess up. The first resolver triggers the message to send, and I can see the message does indeed get sent out and get processed as expected. The msg.on('end', ...) even does not appear to trigger though for the first resolver. The second resolver gets executed and the msg.on('end', ...) does trigger but gets the msg data from the first resolver that was executed. This then appears to continue from that point on causing each following resolver to get the result of the previous instead of the expected result. At the end 2 additional msg.on('end', ...) appear to execute but the first one has the result of the previous resolver and the last one is just a copy of it.
Because the resolvers are actually executing and the "Resolver:" debug line is outputting as expected and the debugging I have done I cannot see any problem the the actual execution of all code surrounding the message handling but rather the problem appears to be with the message processing itself in the following lines...
The variable resPath is a constant generated in a for loop outside of these lines. When ever this code executes, there should be a debug line starting with "Resolver: Some.Path" accompanied by a line starting with "Resolved: Some.Path". If I test this in a simple test environment it works fine all day long. This leads me to believe that there is something in the flow stream handling which appears to be mixing up events or messages.
Am I correct in thinking that this is a discovered bug?
The text was updated successfully, but these errors were encountered: