#Yeah I can file it Can you post your
heavy fiber
import wifi
import socketpool
import adafruit_requests
from secrets import secrets
URL = "http://httpbin.org/post"
wifi.radio.connect(secrets["ssid"], secrets["password"])
pool = socketpool.SocketPool(wifi.radio)
requests = adafruit_requests.Session(pool)
response = requests.post(URL, data='a'*3000) # 2750 works...
print(response.status_code, response.reason)```then I also just put some debug prints into adafruit_requests
I'll attach the modified library
night yarrow
Ah, I was wondering where those DEBUG parts came from! I was wondering if there was some special debug mode I was unaware of. This makes much more sense. 🤦♂️
heavy fiber
it would be handy if Requests had a debug mode 🙂
hang on, put some more prints in and seeing something different
it miscounts the first chunk:DEBUG sent=2880 total_sent=2880
I print it out, there's definitely 3000 there
socket.send is returning the wrong value
night yarrow
Interesting
heavy fiber
may be a bug in an Espressif -included component: https://github.com/adafruit/circuitpython/blob/b2e77bd11a15281702a56296d48bbd74dd7709dd/ports/espressif/common-hal/socketpool/Socket.c#L282
that "sent" value gets passed straight up
no, maybe it's right... that's why it re-sends the 120
no idea why that would result in an error though
night yarrow
I'll keep poking at it some more. If it does look like the Espressif component has a bug, what's the process from there? Do we submit a bug to the Espressif CP port?
heavy fiber
The more I look at it, the core socket isn't able to send all 3000, so it sends 2880. The Requests sends the 120, but the core socket raises the EAGAIN exception, which I understand to mean "try again", but I don't see that Requests tries that 2nd chunk again in that case.
hard to say what's behaving "wrong", probably Requests... EAGAIN is a valid behavior for a non-blocking socket
heavy fiber
my take is it means, hey I can't complete this right now so try again if you want
but I think EAGAIN is typically an exception for socket reads rather than sends
so maybe it is an issue with the lwip component in some way. not sure
no, looks like it's valid for send too
in the core CP socket code, it looks like EAGAIN on receives raise an exception rather than re-trying in the core, so I suspect that's the desired behavior here too... so Requests should notice EAGAIN and retry. I think.
yeah, it works with a retry after EAGAIN, but my implementation was quite kludgy
night yarrow
So should requests retry and just send the remaining data? Or try to send the whole thing again? It's already retrying the whole thing once.
heavy fiber
I think Requests has to retry just the failing chunk
it's taking a little too long for the lwip socket to handle the second chunk after a big first chunk (or something like that)
so it throws up its hands and punts back to the user
night yarrow
so should the except (_SendFailed, OSError) as e: statement be separated out into two separate except statements, and the OSError part handles the EAGAIN?
Funny, I added a bunch of debugging statements in and it started working sometimes (probably because they added enough of a pause to let the socket clear enough of its queue).
heavy fiber
I think it needs to be deeper, in the _send function, otherwise the whole full send is done again and that doesn't solve the last bits that take a little longer?
I've been doing 10-15,000 bytes
(if you were referring to line 719) it's already tried twice as a whole
but the first chunks of a long send seem to work fine, it's more the later chunk(s)