Pico W drops from Web Workflow list of networked CircuitPython devices

[RetiredWizard]

CircuitPython version

Adafruit CircuitPython 8.0.0-beta.5-11-gfc13fba6e-dirty on 2022-12-14; Raspberry Pi Pico W with rp2040

Code/REPL

import wifi
import socketpool
import ssl
import adafruit_requests
from os import getenv

TEXT_URL = "http://wifitest.adafruit.com/testwifi/index.html"

print("Connecting...")
wifi.radio.connect(getenv('CIRCUITPY_WIFI_SSID'),getenv('CIRCUITPY_WIFI_PASSWORD'))
print("My IP address is", wifi.radio.ipv4_address)

pool = socketpool.SocketPool(wifi.radio)
requests = adafruit_requests.Session(pool, ssl.create_default_context())

input("Check web workflow devices on network and then press enter")
response = requests.get(TEXT_URL)
print("Check web workflow devices on network again")

Behavior

When connecting to the Pico W over the USB serial port:
Up until the response = requests.get(TEXT_URL) is executed in the test script above the Pico W is listed by other CircuitPython devices as available on the network. Once the requests.get call is made the Pico W is no longer listed (upon browser refresh) until a Ctrl-D restart occurs.

If the local web workflow server on the Pico W is accessed via a browser (main page, serial terminal, file browser or full terminal), the Pico W is dropped from the available devices list.

Description

Even though the Pico W device is not listed by other devices the Pico W can still be accessed via the microcontroller hosted site and the file browser/serial terminal/info page all work properly.

Additional information

I am testing from a Windows 8 PC and not running mDNS.

[tannewt]

I wonder if the additional requests are turning off the MDNS responder.

[RetiredWizard]

I tested this out on an Feather ESP32-S3 and didn't see the same issue.

[anecdata]

Does the dual-core S3 have an advantage with blocking Python or core code, vs. underlying priorities of core tasks?

[RetiredWizard]

I think the S2 is a single core and I just tested the latest CircuitPython on the QT Py ESP32-S2 and the web workflow didn't drop the device from the list when this code was run.

[dhalbert]

Does the dual-core S3 have an advantage with blocking Python or core code, vs. underlying priorities of core tasks?

I would say not really, the RTOS can take care of allowing the IDF network code to run, on a single core or the other core, if available. If we have something blocking in the Python code that is blocking network code, that is a bug.

[RetiredWizard]

I don't know if it helps but I traced the steps through the adafruit_requests.py library and the line that appears to shutdown the responder is:

524 sock.connect((connect_host, port))

[RetiredWizard]

Looking (and a bit of selective code commenting) in common-hal/socketpool/Socket.c I believe

981 err = tcp_connect(socket->pcb.tcp, &dest, port, _lwip_tcp_connected);

is the line that causes the issue. I took a look at the tcp_connect function in tcp.c and compared it to the same function in esp_tls.c hoping that the comments would suggest a clue. The only thing I noticed (understood) was that the ESP module sets the socket to "non-blocking" before connecting. That sounds to me like it would only impact the process while attempting to make the connection and since the pico w never comes back to the list after executing the requests.get I'm doubtful the non-blocking setting is relevant.