`fetch` method of `PortalBase` tries to keep connecting to WiFi forever if connection cannot be established

[javiser]

Hi,
I noticed something during my project with a PyPortal: when I use the fetch method from a PyPortal object, if the connection with the Wifi cannot be established, the program execution will be stopped there forever. So I decided to have a look at the code of the fetch method in the PortalBase class and I saw that the fetch method supports a timeout parameter, which is even set to 10 by default. So I was wondering why the connection tries would keep going forever.
The timeout parameter is indeed used by the call to the method self._wifi.requests.get in the fetch method of adafruit_portalbase/network.py. But before that, there is a call to the method connect in the same file. And that's where the problem appears to be: there is a loop which becomes infinite:

        while not self._wifi.is_connected:
            ...

There is not an alternative exit point for that loop: either it connects, or it connects. No maximum number of retries, no timeout, just nothing.
I believe that this is a bug or a least a serious candidate for improvement. By understanding this I have implemented this workaround:

try:
    pyportal.network._wifi.connect(pyportal.network._secrets["ssid"], pyportal.network._secrets["password"])
except RuntimeError as error:
    print("Error connecting to WiFi - ", error)
    # Do whatever you want to do with this situation

Only if I don't get an error by this connect attempt, I will call the fetch method, otherwise I won't

[javiser]

Thank you for fixing this!

[javiser]

Hi @makermelissa, today I have been having a more detailed look into this fix and what the implicatons for my code are. Unfortunately I didn't see the PR while it was in review. There are two things that I am not so sure about:

• The optional parameter max_attempts that you have added to the connect() method is not "accessible" from the PyPortal (as child of of PortalBase) object. What I mean is: I can't do something like:

value = pyportal.fetch(max_attempts=3)  # Max. 3 attemps before stop trying to connect

Which would really nice, because - at least in my project - I don't see the need to try 10 times before I stop. I understand that this is a change in the doc as well, and that I still do have the opportunity to do a nicer, cleaner version of my workaround mentioned in my original post, something like:

try:
    pyportal.network.connect(max_attempts=2)
except (RuntimeError, OSError) as error:
    print("Error connecting to WiFi - ", error)
    # Do whatever you want to do with this situation

I tried that by the way, I replaced the network.py locally as the new lib version is not still available via circup. And that's how I noticed the second issue:

• The exception raised for the max_attemps case is OSError, which makes me wonder a little bit. Is this on purpose? I would have rather expected a RuntimeError. This is rather a question than a bug anyway.

I decided not to reopen this issue, because I am not sure what decisions you wanted to make or not. In the end, I still can customize the libraries for my project to my convenience, but for me it is also about making the libraries better and contributing. If there is some additional fix, I offer myself as optional reviewer.

[makermelissa]

We'll probably need to add the change to the PyPortal library as well so you can pass in numbers. It's enabled by default at least.