-
Notifications
You must be signed in to change notification settings - Fork 251
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
Any async delay operation while an aioquic.client object exists makes it silently fail #449
Comments
…esn't break anything right now Signed-off-by: Raven Black <[email protected]>
* Add streaming POST support to h3_request tool this doesn't work if there's input delays, because aiortc/aioquic#449 but it also doesn't break anything right now and should work when the library works correctly. Signed-off-by: Raven Black <[email protected]>
Ah, apparently this is already fixed, I just needed to be on the new version! |
Ah, no, it's not fixed, I just mistakenly did |
I suggest you take a closer look at the You're missing the call to aioquic/examples/http3_client.py Line 240 in 20cd4ee
See: |
In that case isn't there just the opposite bug - if you remove the short sleep it does send the request and get the response even though |
The behaviour is just not defined if you don't call transmit() yourself after queuing data: transmit() can be triggered by receiving data from the server or a timer going off. |
Thanks for the explanation, and sorry for the incorrect noise! |
It's not noise, the feedback is welcome. It made me realise that even though the |
Cool, improved docs are always good. I would suggest that documenting it in |
I initially found this issue while trying to issue a streaming post request; putting a delay between one
send_data
and the next, such that python was async-awaiting input from stdin, caused this same failure. I've narrowed it down to just any async operation that waits at all, any time duringasync with client_resolver
, causes the same effect.Reproduction as minimal as I could make it:
With the tiny sleep, this outputs
and gets stuck there until you ctrl-C.
Without the tiny sleep you get essentially the same four lines (different id obviously) but then it goes on to also output the events containing all the HTML and such, and terminate, as expected.
To be clear, if you add debug prints throughout the code, it does everything the same within this script, send_headers is called etc., and waits for the future at the end of the request function, the difference is just that all the expected QuicEvents don't call the callbacks, so that future never completes.
The text was updated successfully, but these errors were encountered: