-
Notifications
You must be signed in to change notification settings - Fork 6
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
Warnings / Error from Netty in case of failures / suspensions #415
Comments
The thing is, this is completely valid exception, it's telling you that the response is already written because the stream was closed before (that's the Error from the wire you see in the second line), so I don't think we should simply hide that/ignore that. It is basically telling you we're dropping some data effectively. Maybe we just need to lower down the level when we have these exceptions to DEBUG? |
I don't quite understand - who closed the stream, the SDK or Restate server? If the server closed the stream, than this is valid and expected and should probably just be on DEBUG, with an additional info that this can be because the server closed the stream. If the SDK closed the stream and still tried to write, than this is a bit strange. Might be harmless (because of how committed journal is the only ground truth) but still strange that the SDK tries to write after it closed the stream itself. Some kind of accidental concurrency? |
This is the case here, you can see it here:
I'll lower this down to debug |
Can you add an error message that describes the situation, like "Restate Server closed the stream - this may be due to a request to suspend, or due to fencing off this invocation." |
I see this happening in some examples where some operations (RPCs) cannot complete because the target service is not yet deployed, and the code suspends.
Steps to reproduce:
BookingWorkflow
, NOT the activity servicescurl localhost:8080/BookingWorkflow/abc/run --json '{}'
The text was updated successfully, but these errors were encountered: