Persistent failures after DNS glitch

[gdt]

I'm helping someone set up weewx with a WLL for a VP2. Both are on ethernet. The router is glitchy and sometimes fails to respond to DNS queries for mdns. The router does not support static-mapped DHCP. That's all a mess, and not the driver's fault. The computer is a RPI3, running NetBSD with python 3.11. An identical computer with identical sw -- just not this driver -- works 100% solidly with a VP2, staying up except for power, and not having problems at all.

From time to time, the dns lookup fails, and it keeps trying. often it's ok.
Sometimes, there are further issues, and it gets into a state where I get three lines

ERROR user.weatherlink_live.scheduler: Error caught in scheduler tick. Not rescheduling
WARNING user.weatherlink_live.driver: No data since 1 iterations
CRITICAL __main__: Caught WeeWxIOError: Error while receiving or processing packets: ConnectionError(MaxRetryError('HTTPConnectionPool(host=\'wea\
therlinklive.lan\', port=80): Max retries exceeded with url: /v1/current_conditions (Caused by NameResolutionError("<urllib3.connection.HTTPConnection object at 0x782b8e90>: Failed to re\
solve \'weatherlinklive.lan\' ([Errno 7] No address associated with hostname)"))'))

followed by

CRITICAL __main__: Caught WeeWxIOError: Error while receiving or processing packets: OSError(48, 'Address already in use')

I'm way out on a limb, but it looks like failure to close the listening socket for UDP when handling the error. And the scheduler tick error looks suspicious too.

Code is up-to-date driver (git head from a week ago), and old 4.8 weewx. It's on my list to update weewx to 5.x, but that's harder because of the changing of the install method so it will take me a bit. Reading commit logs I don't see a breakage of older weewx, and this error seems like it's in the driver.

I'm going to try to read the code and figure this out, but thought I'd mention it, see if anybody has thoughts.

[michael-slx]

I can confirm the first output you provided is normal given the DNS issues.

Regarding the second output: I've just pushed a commit to a new branch bugfix/close-on-error. Would it be possible for you to try it out and see if you still get that output?

[gdt]

Thanks for the very fast fix. Sure, happy to test and review.

I also have some commits, not yet pushed, to fix a logging buglet, and some close/null hygiene, but I'll try just your branch first, and then see what of my changes still make sense.

[michael-slx]

OK, thanks!

[gdt]

The new code has been running since about 23Z on the 15th. I'll watch for a real timeout; so far there have been two instances where the first retry (attempt #1 in code terms) worked.

[gdt]

There was a full failure, where all 3 attempts didn't work. I've attached the log output, minus preamble/hostname/time, but once the failure happens it's all within about 2s.
wll-timeout.txt

I'm still running it, because the 2nd time might be different.

[michael-slx]

The first stack trace in your log is normal with register to the DNS problems. I've pushed a new commit to the bugfix branch that should fix the second issue.

[gdt]

Thanks - updated code running.

[gdt]

There was another connection problem. First error 165018Z today, and last error 171340Z. I got a reconnection alert at 1715, due to it posting data over mqtt at the 5min archive interval.

The only thing I'd say isn't right is that there is no report of success at the same critical log level, once, following a critical report of failure. Perhaps that should be inferred, and this is just my preference. But obviously that is really not a big deal and the important thing is that it reconnected.

So I'd say merge this to master, please. Thanks for address my bug report in discussions :-)

[gdt]

moved to #42