-
Notifications
You must be signed in to change notification settings - Fork 422
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
Chunked transmission lasts longer than timeout #4214
base: master
Are you sure you want to change the base?
Conversation
2244b8c
to
aded4cc
Compare
...ty-server/cats/src/test/scala/sttp/tapir/server/netty/cats/NettyCatsRequestTimeoutTest.scala
Outdated
Show resolved
Hide resolved
There are two differences compared to the original report:
|
*Why I did it?* In order to have a test which might confirm an issue with an interrupted request *How I did it:* I prepared `NettyCatsRequestTimeoutTest` with the folloing test scenario: - send first chunk (100 bytes) - sleep - send second chunk (100 bytes)
- add PlayServerTest instead of NettyCatsServerTest - improve fs2 implementation
49a1e12
to
ad42e13
Compare
Thanks for your precise comment. I've rewritten it to |
.streamBody(Fs2Streams[IO])(inputStream) | ||
.send(backend) | ||
.map{ response => | ||
response.code shouldBe StatusCode.Ok |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm well if this test passes, something is wrong - we set the timeout to 1s, so we should never receive a response if it takes 2s to send it? unless the request timeout is for something else?
anyway, this doesn't test the scenario from the test case - where the transmission is interrupted half-way because of connection problems; I don't know if we can simulate this in a test case, but using a timeout is a good approximation. But probably a good way to check if we can at all reproduce the bug is to run: a long-running client sender process; a server process; then kill -9
the client process when it's half-way sending the data, and seeing on the server if received the incomplete data in the server logic
Why I did it?
In order to have a test which might confirm an issue
with an interrupted request
How I did it:
I prepared
NettyCatsRequestTimeoutTest
with the folloing test scenario:Closes #4169