Paste in Web Workflow terminal often causes issues

[tyeth]

CircuitPython version

8.1 latest git on equivalent of Adafruit Huzzah ESP32, but really a lilygo/ttgo t-sim7000g.

Observations

I'm just trying this board out and have been seeing this issue regularly while pasting in things to the web Serial Terminal, doesn't matter if using mDNS or IP to access, but comes up with this console error and there is no way to re-enable the websocket. Refreshing once doesn't resolve, but after 3times works (maybe websockets on device are not being closed correctly until another connection arrives and pool gets cleared). Other web workflow pages refresh fine.

The clearest example seems to be pasting in this line to the input box pin = machine.Pin(0, machine.Pin.IN, machine.Pin.PULL_UP) and then going with the cursor (mouse click) to add a 1 after pin, which somes before and sometimes after editing locks up the web terminal with the following error in console:
WebSocket connection to 'ws://192.168.0.39/cp/serial/' failed: Could not decode a text frame as UTF-8.
It seems to just happen a lot on paste, irrespective of what you do afterwards in the input box.

[DavePutz]

Verified that the problem exists on ESP32-S2 and ESP32-S3 with the latest build as well; but not on a PICO-W. The issue seems to be tied to overflows on the receiving ring buffer that are not being checked for in websocket_background().

[tannewt]

@DavePutz are you working on a fix?

[DavePutz]

@tannewt Yes. I have seen that by increasing the size of _buf in supervisor/shared/web_workflow/websocket.c the issue can be avoided; at least until the size of _buf is exceeded again. This does not look like a great fix to me, so I am trying to see why the buffer is overflowing in the first place.

[tannewt]

@DavePutz seems like we may not want to take bytes from the socket if the ringbuf is full.

[DavePutz]

So, it looks like this issue is caused by the placement of RUN_BACKGROUND_TASKS in socketpool_socket_recv_into() for espressif boards. When web workflow is active; the code:

    while (ringbuf_num_empty(&_incoming_ringbuf) > 0 &&
           _read_next_payload_byte(&c)) {

in websocket_background() means that after the test for ringbuf_num_empty is done, calling _read_next_payload_byte() can eventually result in background calls, thus ending up calling websocket_background() again. The Pico W works because there is no call to RUN_BACKGROUND_TASKS in socketpool_socket_recv_into(). @tannewt ; is the RUN_BACKGROUND_TASKS necessary? I took it out (which fixed this issue) and other things seemed to run OK; but I'm not sure what side effects might be caused.

[tannewt]

I'm not sure it is necessary. It might be an artifact of using blocking sockets during development. I'd suggest moving it to the bottom of the while loop so it only happens if we go around the loop again.

[dhalbert]

Fixed by #7694.