-
Notifications
You must be signed in to change notification settings - Fork 654
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
Version [email protected] is broken #2318
Comments
We've also seen issues with 1.18.2 today. Initially it looked like a programming error that triggered the steam to close. On a full duplex stream, a message is sent from client to server, the client always to instantly close the stream before the server can respond |
Can you share a trace of a client doing that, which you would get by running the client with the environment variables |
Due to issue grpc/grpc-node#2318
Due to issue grpc/grpc-node#2318
@murgatroid99 thanks will try and get the information - I see there's a PR as well; if there's a build for that available might be able to try it as well |
I published version 1.8.3 with the change from that PR. Please try it out. |
I also observe the same strange behavior: my app silently exits unexpectedly. So I had to downgrade the package version even to 1.7.3. The message I get when I use the debugger in the WebStorm is The most strange thing is that using |
What do you mean by "Unfortunately, I cannot trace the reason even with debug env variables turned on."? Does it not output anything at all? |
It outputs a lot of info, but I can't find there the reason why the process stops silently. |
The fact that disabling service config resolution stops the problem is especially weird because as far as I can remember, the only thing that has changed about the TXT resolution code path is adding that option to skip that code path. One possibility is that the TXT resolution is actually succeeding, and that is triggering the use of a service config that causes some misbehavior in other new code. |
Somewhere after v1.8.1 (works)
v1.8.2 (no work, at least from the client's perspective)
|
Those are not the logs I asked for. Please share the gRPC trace logs that are produced using the environment variables I specified in my previous comment. |
Both of those (both client and server side, in both 1.8.1 and 1.8.2) were ran with the env vars you asked for. My server script for example ran with this:
Not sure why GRPC stuff isn't coming through. |
I don't understand this. Your server logs include some of the expected trace logs, but not all of them. And your client logs don't include any of those trace logs. What do you get if you don't include the |
Definitely strange :( Forgive some of my own application logs. v1.8.1
v1.8.2
|
Hi @murgatroid99 with respect to the issue mentioned in hyperledger/fabric-chaincode-node#372 we are still facing it when we use the 1.8.3 version of grpc-js |
I have published a likely fix for this in version 1.8.4. Please try it out. |
For my simple test/use-case above it seems to have resolved the issue. Thanks! |
Thank you very much. I can confirm that version |
@murgatroid99 I tried with 1.8.4v too still getting the error(mentioned below), the peer to chaincode connection is instantly dropping
|
Was having the same issue, and FYI: Original issue could be worked around if there was any other ref alive (eg. |
Hi @nikopavlica , can you share/refer to an example of the workaround you found to bypass this ? Do you require this change you are mentioning while using 1.8.4v also ? |
If it is the same problem that @nikopavlica had, you can work around it by calling |
This seems to have regressed in 1.8.5 again... |
@yamen Can you share a trace log from a client that experiences this error, which you would get by running the client with the environment variables |
I just made a change in version 1.8.6 that might fix things. Please try it out, and if you're still having the problem, the trace log will still be useful. |
OK 1.8.6 still exits early, here is the trace log when it fails:
And here is one where I add an open ref so that it succeeds:
I've kept the Extra notes:
|
I would bet that the issue in 1.8.4 where the script wouldn't finish was caused by the bug that was fixed in 1.8.5. That bug was also coincidentally shadowing this bug that you are experiencing now. Specifically, the deadline timer holds a ref, and prior to 1.8.5, it would continue running after the call ended. Your first call has a deadline, and it was long enough that it would keep the process alive through the rest of your script. |
OK, another attempt, please try version 1.8.7. |
Success! Awesome job |
Problem description
When updating to version 1.8.2 our scripts randomly stops without errors. It works when version is pinned to 1.8.1. I have not investigated further.
Environment
The text was updated successfully, but these errors were encountered: