#MagTag and PortalBase race condition with requests
1 messages · Page 1 of 1 (latest)
If you simply comment out all the Google stuff from the example (including the creation of a session object), the code runs fine.
Where it fails, however, is line 423 in adafruit_requests.py, which is _get_socket.
I have pointed Melissa to this.
Excellent.
I think it's probably a pretty easy fix, I am just not familiar enough with this. It's just trying to clear sockets that aren't there because they belong to a different session, basically.
Could you file an issue to the library about this?
There's one already, I'll add this info. I just wanted to make sure I wasn't wasting people's time.
This was originally found by a user in the forums at https://forums.adafruit.com/viewtopic.php?f=19&t=184484&p=895677. I was able to reproduce the issue by following the guide at ht...
That's the issue.
Correction: the issue is that there can only be one socket pool per radio. Still working on write-up.
This was originally found by a user in the forums at https://forums.adafruit.com/viewtopic.php?f=19&t=184484&p=895677. I was able to reproduce the issue by following the guide at ht...
it's just an issue with the example probably having been written for CP6.
@light jay @random totem I have found a fix for the issue, and it doesn't require any modifications of the libs, other than maybe allowing passing in secrets when instantiating a new MagTag and subsequently PortalBase instance.
excellent
And now, 3D-printing a case for this dang MagTag.
It's been updating without fail every 2 minutes for at least 20 minutes now
so this probably addresses issues with all kinds of code that people have all these wild retries in
CC @proper grove
Weirdness. I switched back to the mpy libs, and I am now seeing errors again.
Thanks for figuring that out. Which example are you referring to? I'm drawing a blank here.
I'll go through this in the morning, thank you for digging into it! Did you ever give wrapping thing in a try/except loop? If so did that ever work?
I think I came up with a solution for this particular case. Since it's using deep sleep, the solution is basically to just run the date stuff before any of the Google stuff and it works.
When you mix the internal MagTag/PortalBase network commands with others, that's when this happens.
As long as the MagTag get_local_time or whatever runs first, it all works
Huh. Interesting. Good to know. Thank you for digging into it! Hopefully it'll help digging further as anecdata pointed out there's some other funkiness out there with the networking stuff