Skip to content

Question regarding get_socket error reporting #14

Closed
@RetiredWizard

Description

@RetiredWizard

The Nano Connect has a shorter range than some other boards I use and I sometimes have connection failures only because my office is at the edge of it's range from the access point. Recently while testing connection_manager this error was raised during a connection_manager.get_socket call:

Traceback (most recent call last):
  File "/lib/adafruit_connection_manager.py", line 301, in get_socket
  File "/lib/adafruit_connection_manager.py", line 65, in connect
  File "adafruit_esp32spi/adafruit_esp32spi_socket.py", line 88, in connect
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 819, in socket_connect
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 715, in socket_open
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 341, in _send_command_get_response
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 297, in _wait_response_cmd
  File "adafruit_esp32spi/adafruit_esp32spi.py", line 206, in _wait_for_ready
TimeoutError: ESP32 not responding

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 23, in <module>
  File "adafruit_requests.py", line 591, in get
  File "adafruit_requests.py", line 525, in request
  File "/lib/adafruit_connection_manager.py", line 312, in get_socket
RuntimeError: Error connecting socket: ESP32 not responding

It's not really practical for me to test this since the range connection issues are hard to reproduce and when they occur throw exceptions at different points in the process, however this error stood out to me because it suggested something other than a typical connection difficulty. In looking at the code I see that get_socket tries twice to make the connection and I think, at least with the ESP32SPI hardware, if the first connection attempt fails the hardware is left in an unresponsive state which would explain the error message. I suppose it's possible there is a way to reset and try again but I don't think that's worth it, especially if we could display a more appropriate message. I'm thinking that the error returned from the first attempt might be better so I was wondering what you thought about only setting the last_exc variable on the first try?

Given the difficulty testing this and that I could be wrong about exactly what's happening in this case, I'm not convinced a change makes sense, but figured I'd bring it up, just in case you look it over and say "Oh yea, that makes perfect sense" 😁

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions