WebUI effects list is (sometimes) incomplete or broken when using a slow connection (PPP over UART)

[aenertia]

WLED pins Aircoookie/ESPAsyncWebServer at ac44e32. In AsyncAbstractResponse::_ack() (WebResponses.cpp), the RESPONSE_WAIT_ACK exit condition:

} else if (_state == RESPONSE_WAIT_ACK) {
    if (!_sendContentLength || _ackedLength >= _writtenLength) {
        _state = RESPONSE_END;
        if (!_chunked && !_sendContentLength)
            request->client()->close(true);
    }
}

On the chunked path (_sendContentLength=false), !_sendContentLength is unconditionally true — close() fires as soon as the final zero-length chunk lands in the lwIP send buffer, not when it's ACKed. On fast WiFi the gap is negligible. On slow or high-latency transports (PPP/UART, congested WiFi with retransmissions) the response is truncated before the tail bytes drain.

AsyncBasicResponse::_ack() in the same file already uses _ackedLength >= _writtenLength unconditionally (lines 320-323). AsyncAbstractResponse was never updated to match.

Fork comparison

Fork	AsyncAbstractResponse WAIT_ACK condition	Status
Aircoookie ac44e32 (pinned)	!_sendContentLength || _ackedLength >= _writtenLength	Buggy
me-no-dev AsyncAbstractResponse	!_sendContentLength || _ackedLength >= _writtenLength	Buggy
me-no-dev AsyncBasicResponse lines 320-323	_ackedLength >= _writtenLength	Fixed — inconsistent in same file
mathieucarbou	!_sendContentLength || _ackedLength >= _writtenLength	Buggy
ESP32Async 747223f02f8e	Unconditional _state = RESPONSE_END	Addressed — relies on _onAck for graceful close

Workaround

#5808 avoids the buggy path at the WLED level by switching respondModeData() and respondModeNames() from sendChunked() to request->send() with a pre-computed Content-Length. Not a fix — other endpoints using sendChunked() remain exposed.

Fix options

Match AsyncBasicResponse — drop the !_sendContentLength shortcut:

} else if (_state == RESPONSE_WAIT_ACK) {
    if (_ackedLength >= _writtenLength) {
        _state = RESPONSE_END;
    }
}

Or pull the ESP32Async approach (747223f02f8e) into the Aircoookie pin.

Discussion filed at ESP32Async: ESP32Async/ESPAsyncWebServer#472

[softhack007]

@aenertia I think a good old problem description - from your "users" perspective - would help us to keep the discussion together. It might be better to have this before we jump into suspected root causes and possibly wrong fixes.

The higher level problem is that you observed truncated responses to /json/effects, right? And the environment for the problem is a slow TCP connection, in your case running via PPP instead of Wi-Fi? You are using a "classic" esp32 without PSRAM?

What is the "frontend" you use? WLED's own WebUI, Homeassistant WLED integration, WLED app, or other, maybe your own app?

Do you have an example that reproduced the problem, with expected and actual result?

[aenertia]

Observed via the WLED web UI accessed directly over a PPP link (169.254.x.x, USB serial at 1.5Mbaud). Tested across multiple browsers -- same result. The FX page either renders an incomplete effects list or fails to populate at all. The symptom is consistently worse the more effects are compiled in; with the current uncapped effect count the payload is large enough to trigger it reliably. `curl` against the same endpoints tends to succeed -- my working assumption is that curl completes the HTTP transaction cleanly in one shot, whereas the browser JS path involves the page making the request mid-render with other concurrent activity on the connection. Worth noting: on this hardware (ESP32-PICO-D4, no PSRAM) we run with `WS_MAX_QUEUED_MESSAGES=2` and `DEFAULT_MAX_WS_CLIENTS=1` to keep heap headroom. The reduced WS queue means there's less buffer to absorb the slow link, and we've had to tune `CONFIG_LWIP_TCP_WND_DEFAULT=5744` as well. So the environment is more constrained than a stock WLED build, which may be amplifying whatever the underlying issue is. Same device and firmware on WiFi: FX page loads fine. On PPP: broken. The fix (switching those two endpoints to Content-Length) resolved it. Whether the root cause is what I originally described is less clear now following willmmiles's correction, but the failure mode and the fix are both reproducible.

…

On Sun, 23 Aug 2026 at 22:08, Frank Möhle ***@***.***> wrote: *softhack007* left a comment (wled/WLED#5813) <#5813 (comment)> @aenertia <https://github.com/aenertia> I think a good old problem description - from your "users" perspective- would help us to keep the discussion together. It might be better to have this before we jump into suspected root causes and possibly wrong fixes. The higher level problem is that you observed truncated responses to /json/effects, right? And the environment for the problem is a slow TCP connection, in your case running via PPP instead of Wi-Fi? What is the "fronend" you use? WLED's own WebUI, Homeassistant WLED integration, WLED app, or other? Do you have an example that reproduced the problem, with expected and actual result? — Reply to this email directly, view it on GitHub <#5813?email_source=notifications&email_token=AACF5L65TTQOBCTKVIWR4D35LK7B7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYGU2DIOBXGI4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5385448728>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACF5L7P5JUAFZ5V5XHAFLT5LK7B7AVCNFSNUABEKJSXA33TNF2G64TZHM3TMOJZGAZDAOJ3JFZXG5LFHM2TEMRUGU4DAMRSHCQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AACF5L4K344VRP625JJEGL35LK7B7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYGU2DIOBXGI4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AACF5L3BTFCCZLP45VJOTK35LK7B7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYGU2DIOBXGI4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[softhack007]

curl` against the same endpoints tends to succeed

@coderabbitai please check if our WebUI implementation ( /wled00/data/index.js) causes the TCP transfer to work differently from directly reading the response with "curl". The WebUI client runs in the user's browser - typically MS edge, chrome, or Firefox.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '== Requested WebUI file outline =='
ast-grep outline wled00/data/index.js --items all || true

echo
echo '== WebUI references to effects JSON and fetch/XHR primitives =='
rg -n -C 5 -i \
  'json/effects|effects\.json|fetch\s*\(|XMLHttpRequest|\.open\s*\(|\.send\s*\(' \
  wled00/data/index.js || true

echo
echo '== Repository references to /json/effects and likely handlers =='
rg -n -C 5 --glob '!wled00/data/index.js' \
  '[/"]json/effects|json/effects|effects.*json|serve.*effects|effects.*serve' \
  . || true

echo
echo '== Candidate HTTP response framing calls near effect handlers =='
rg -n -C 5 \
  'beginResponse|beginResponse_P|send_P|setContentLength|CONTENT_LENGTH_UNKNOWN|ChunkedResponse|AsyncResponseStream|request->send' \
  . || true

Length of output: 40124

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '== WebUI URL construction and startup sequence =='
sed -n '220,330p' wled00/data/index.js

echo
echo '== WebUI effect, palette, and preset request functions =='
sed -n '510,590p' wled00/data/index.js

echo
echo '== WebUI WebSocket lifecycle =='
sed -n '1420,1475p' wled00/data/index.js

echo
echo '== WebUI state request transport =='
sed -n '1750,1815p' wled00/data/index.js

echo
echo '== JSON endpoint routing and effect response generation =='
sed -n '1280,1440p' wled00/json.cpp

echo
echo '== Route registration for JSON endpoints =='
rg -n -C 8 'serveJson|/json|jsonHandler|on\(.*json' wled00/wled_server.cpp wled00/*.h

Length of output: 27697

---

@softhack007, I checked the WebUI request path and the JSON handler.

The WebUI does not use a special TCP transfer method for /json/effects.

• wled00/data/index.js sends a normal same-origin Fetch GET request in loadFX():

  fetch(getURL('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/json/effects'), {method: 'get'})

• It calls res.json(). This call completes only after the browser receives the full HTTP response body and parses valid JSON.
• The WebUI does not read the body incrementally, cancel the request, or set connection-related Fetch options.
• loadFX() retries a failed request up to five times. It then populates the list only after JSON parsing succeeds.

The initial WebUI requests are sequential:

1. /json/palettes
2. /json/fxdata
3. /json/effects
4. /json/si

The WebUI creates the WebSocket only after this sequence completes. Therefore, the WebUI does not create WebSocket traffic concurrent with the initial /json/effects request.

The server code also shows that /json/effects has a known response length:

• /json/effects routes to serializeModeNames().
• The handler calls response->setLength() before request->send(response).

The chunked response code is for /json/fxdata, not /json/effects. loadFXData() runs before loadFX(), but it completes or exhausts its retry handling before the effects request starts.

A browser and curl can still use different persistent-connection behavior and request headers. However, the inspected WebUI code does not select a different protocol, transfer encoding, or concurrent request pattern for /json/effects. The current source does not support the hypothesis that Fetch itself causes /json/effects to transfer differently from a direct curl GET.

_{You are interacting with an AI system.}

[softhack007]

@coderabbitai the problematic call might be /json/fxdata which is also needed to construct the effects list in the WebUI. Please repeat your analysis in #5813 (comment) for this endpoint.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '== WebUI structure =='
ast-grep outline wled00/data/index.js --items all --type function || true

echo
echo '== JSON server structure =='
ast-grep outline wled00/json.cpp --items all --type function || true

echo
echo '== WebUI /json/fxdata references and request sequence =='
rg -n -C 12 \
  'loadFXData\s*\(|loadFX\s*\(|/json/fxdata|fetch\s*\(|res\.json\s*\(' \
  wled00/data/index.js

echo
echo '== Server /json/fxdata route and response implementation =='
rg -n -C 15 \
  'fxdata|serialize.*FX|serialize.*Mode|beginResponse|AsyncResponseStream|ChunkedResponse|setLength|CONTENT_LENGTH_UNKNOWN|Transfer-Encoding' \
  wled00/json.cpp wled00/wled_server.cpp wled00/*.h

echo
echo '== Request-header or connection-specific handling =='
rg -n -C 8 \
  'User-Agent|Accept-Encoding|Connection|keep-alive|HTTP/1\.0|HTTP/1\.1|chunked|Transfer-Encoding' \
  wled00 --glob '*.{cpp,h,js}'

Length of output: 56907

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '== /json/fxdata handler =='
sed -n '1250,1358p' wled00/json.cpp

echo
echo '== JSON route registrations and dispatch =='
rg -n -C 18 \
  'respondModeData\s*\(|serveJson\s*\(|/json/fxdata|json_target|fxdata' \
  wled00 --glob '*.{cpp,h}'

echo
echo '== Async response implementation candidates =='
fd -t f . wled00/src/dependencies | rg 'Async.*(WebServer|Json)|WebServer.*Async|AsyncJson'

echo
echo '== Response framing implementation references =='
rg -n -C 10 \
  'class .*Response|_contentLength|setLength\s*\(|_fillBuffer\s*\(|RESPONSE_STREAM|RESPONSE_CALLBACK|chunked' \
  wled00/src/dependencies --glob '*.{cpp,h}'

Length of output: 28737

---

@softhack007, you are correct. My prior conclusion addressed the wrong endpoint.

/json/fxdata is a materially different response path from /json/effects.

• wled00/data/index.js calls loadFXData() before loadFX().
• loadFXData() sends a normal Fetch GET request to /json/fxdata.
• It waits for res.json() before it starts /json/effects.
• The WebSocket starts only after both requests complete.

The server routes /json/fxdata to respondModeData() in wled00/json.cpp.

request->sendChunked(FPSTR(CONTENT_TYPE_JSON), ...);

This handler streams the mode-data JSON in blocks. It does not calculate or send a Content-Length. The callback retains fx_index and produces more JSON when the async server requests the next output block.

Therefore, the browser receives /json/fxdata as a chunked HTTP response. /json/effects uses a different path. Its LockedJsonResponse calls response->setLength() before it sends the response.

The WebUI does not set Fetch options that change TCP behavior. However, /json/fxdata does use different HTTP response framing from a Content-Length response. This makes /json/fxdata the relevant endpoint for the reported PPP failure.

The source does not explain why curl usually succeeds. Curl and modern browsers both support chunked responses. A browser can reuse a persistent connection and can send different request headers. Those differences are outside index.js. The source-level evidence does support testing the change from sendChunked() to a known-length response for /json/fxdata on the PPP link.

_{You are interacting with an AI system.}

[softhack007]

@coderabbitai please also inspect the user's ppp source code (https://github.com/aenertia/WLED/blob/dev/ppp-wifi/wled00/wled_ppp.cpp) against the problem description. Could it be that an error in the new PPP code (off-by-one, buffer overflow, exhaustion on queues, etc) causes the observed behaviour?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

repo='aenertia/WLED'
ref='dev/ppp-wifi'

echo '== Exact requested file =='
gh api "repos/${repo}/contents/wled00/wled_ppp.cpp?ref=${ref}" \
  --jq '.content' | base64 -d | nl -ba

echo
echo '== Related PPP source/header files in the branch =='
gh api "repos/${repo}/git/trees/${ref}?recursive=1" --paginate \
  --jq -r '.tree[].path' | rg -i '(^|/)(wled_ppp|.*ppp.*|platformio.*|sdkconfig.*|.*config.*)\.(cpp|c|h|ini|defaults|csv)$' || true

echo
echo '== All wled_ppp references in branch source =='
gh api "repos/${repo}/git/trees/${ref}?recursive=1" --paginate \
  --jq -r '.tree[].path' | while IFS= read -r f; do
    case "$f" in
      *.c|*.cc|*.cpp|*.h|*.hpp|*.ini|*.defaults)
        content=$(gh api "repos/${repo}/contents/${f}?ref=${ref}" --jq '.content' 2>/dev/null | base64 -d 2>/dev/null || true)
        if printf '%s' "$content" | rg -q 'wled_ppp|PPP_|pppos|pppapi'; then
          printf '\n--- %s ---\n' "$f"
          printf '%s\n' "$content" | rg -n -C 4 'wled_ppp|PPP_|pppos|pppapi'
        fi
        ;;
    esac
  done

Length of output: 1445

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

repo='aenertia/WLED'
ref='dev/ppp-wifi'

get_file() {
  gh api "repos/${repo}/contents/$1?ref=${ref}" --jq '.content' | base64 -d
}

echo '== wled00/wled_ppp.cpp =='
get_file 'wled00/wled_ppp.cpp' | awk '{printf "%6d  %s\n", NR, $0}'

echo
echo '== Files adjacent to the PPP implementation =='
gh api "repos/${repo}/contents/wled00?ref=${ref}" --jq -r '.[].path' | rg -i 'ppp|serial|net|config|wled\.h'

echo
echo '== PPP-related configuration and declarations =='
for f in \
  wled00/wled.h \
  platformio.ini \
  platformio_override.ini \
  sdkconfig.defaults \
  sdkconfig.defaults.esp32 \
  wled00/wled_server.cpp; do
  if gh api "repos/${repo}/contents/${f}?ref=${ref}" >/dev/null 2>&1; then
    echo "--- ${f} ---"
    get_file "$f" | rg -n -C 5 'wled_ppp|PPP_|pppapi|pppos|LWIP|TCP_WND|QUEUED|Serial|UART' || true
  fi
done

Length of output: 23544

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

base='https://raw.githubusercontent.com/aenertia/WLED/dev/ppp-wifi'

fetch() {
  printf '\n===== %s =====\n' "$1"
  curl -fsSL "${base}/$1" || true
}

fetch 'wled00/wled_ppp.h'
fetch 'platformio.ini'
fetch 'platformio_override.ini'
fetch 'sdkconfig.defaults'
fetch 'sdkconfig.defaults.esp32'
fetch 'wled00/wled.h'

echo
echo '===== PPP-related files and configuration paths in branch ====='
curl -fsSL 'https://api.github.com/repos/aenertia/WLED/git/trees/dev/ppp-wifi?recursive=1' |
  jq -r '.tree[].path' |
  rg -i '(^|/)(wled_ppp|sdkconfig|platformio|partitions|.*ppp.*)\b' || true

echo
echo '===== ESP-IDF / framework version references ====='
for f in platformio.ini platformio_override.ini; do
  curl -fsSL "${base}/${f}" 2>/dev/null |
    rg -n -C 3 'platform|framework|espressif32|arduino-esp32|idf|version' || true
done

Length of output: 240912

---

🤖 web_search executed:

ESP-IDF 5.3 esp_netif_receive buffer ownership caller buffer lifetime documentation

Length of output: 8665

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '== ESP-IDF v5.5.4: esp_netif_receive implementation and PPP input path =='
for f in \
  components/esp_netif/lwip/esp_netif_lwip.c \
  components/esp_netif/lwip/esp_netif_lwip_ppp.c \
  components/lwip/lwip/src/netif/ppp/pppos.c \
  components/lwip/lwip/src/netif/ppp/ppp.c; do
  url="https://raw.githubusercontent.com/espressif/esp-idf/v5.5.4/${f}"
  echo "--- ${f} ---"
  curl -fsSL "$url" |
    grep -n -E -C 8 'esp_netif_receive|pppos_input|ppp_input|netif_receive|tcpip_inpkt|tcpip_input' || true
done

echo
echo '== Commits affecting PPP transport files in the requested branch =='
gh api 'repos/aenertia/WLED/commits?sha=dev%2Fppp-wifi&path=wled00%2Fwled_ppp.cpp&per_page=100' \
  --jq '.[] | [.sha[0:12], .commit.author.date, .commit.message] | `@tsv`' || true

echo
echo '== Diff of PPP transport file against upstream WLED dev, if available =='
curl -fsSL 'https://raw.githubusercontent.com/wled/WLED/dev/wled00/wled_ppp.cpp' \
  -o /tmp/upstream_wled_ppp.cpp || true
curl -fsSL 'https://raw.githubusercontent.com/aenertia/WLED/dev/ppp-wifi/wled00/wled_ppp.cpp' \
  -o /tmp/aenertia_wled_ppp.cpp
if [ -s /tmp/upstream_wled_ppp.cpp ]; then
  diff -u /tmp/upstream_wled_ppp.cpp /tmp/aenertia_wled_ppp.cpp | sed -n '1,260p' || true
else
  echo 'No upstream wled_ppp.cpp exists on WLED dev.'
fi

Length of output: 5283

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '== ESP-IDF v5.5.4: complete esp_netif_receive() =='
curl -fsSL 'https://raw.githubusercontent.com/espressif/esp-idf/v5.5.4/components/esp_netif/lwip/esp_netif_lwip.c' |
  sed -n '1388,1455p'

echo
echo '== Locate pppos_input_tcpip_as_ram_pbuf() in ESP-IDF v5.5.4 tree =='
curl -fsSL 'https://api.github.com/repos/espressif/esp-idf/git/trees/v5.5.4?recursive=1' |
  jq -r '.tree[].path' |
  grep -E '(^|/)(pppos\.c|pppapi\.c|ppp.*\.c)$' |
  while IFS= read -r f; do
    content=$(curl -fsSL "https://raw.githubusercontent.com/espressif/esp-idf/v5.5.4/${f}" || true)
    if printf '%s' "$content" | grep -q 'pppos_input_tcpip_as_ram_pbuf'; then
      echo "--- ${f} ---"
      printf '%s\n' "$content" |
        grep -n -E -C 18 'pppos_input_tcpip_as_ram_pbuf|pppos_input_tcpip|pbuf_alloc|pbuf_take'
    fi
  done

echo
echo '== Error return handling in current PPP receive loop =='
curl -fsSL 'https://raw.githubusercontent.com/aenertia/WLED/dev/ppp-wifi/wled00/wled_ppp.cpp' |
  sed -n '394,424p'

Length of output: 6328

---

@softhack007, yes. The PPP implementation has defects that can cause packet loss under load. It can amplify the /json/fxdata failure. I cannot prove from source inspection that it is the only root cause.

Confirmed findings

1. The code discards PPP input bytes.

   At wled00/wled_ppp.cpp Lines 405-410, ppp_rx_task() calls:

   uart_flush_input(PPP_UART_NUM);

   when the UART RX ring has more than 12,288 bytes pending.

   The PPP build uses an 8,192-byte nominal RX buffer and a 16,384-byte UART RX ring. This flush discards partial and complete HDLC frames. PPP rejects a corrupted frame. TCP then must retransmit the lost segment.

2. The selected build has a small TCP/IP input mailbox.

   platformio_override.ini sets:

   CONFIG_LWIP_TCPIP_RECVMBOX_SIZE=4

   ESP-IDF sends PPP input to tcpip_inpkt(). The PPP receive path allocates a RAM pbuf, copies the UART bytes, then queues the pbuf to the TCP/IP thread.

   A mailbox depth of four can fill during bursts. When it fills, PPP input can fail with ERR_MEM. The current configuration does not enable CONFIG_ESP_NETIF_RECEIVE_REPORT_ERRORS, so esp_netif_receive() returns ESP_OK even when the PPP adapter rejected the input. The code at Line 420 also does not have an error path or a counter for this condition.

3. The code writes plain diagnostic text to the active PPP UART.

   wled00/wled_ppp.cpp calls uart_write_bytes() for diagnostics at:

   • Lines 199-205
   • Lines 258-265
   • Lines 476-485

   The UART is the PPP byte stream after Serial.end() and uart_driver_install(). Diagnostic text is not valid PPP traffic. It can corrupt an outgoing PPP frame or create an invalid frame at the peer. This is a protocol error.

   The periodic diagnostic task does this every 30 seconds. It does not explain every failed request, but it can cause intermittent loss and make timing-sensitive failures worse.

Findings that are not confirmed

• I found no direct off-by-one read in ppp_rx_task(). uart_read_bytes() receives at most sizeof(buf), and buf is 1,024 bytes.
• The stack lifetime is safe. ESP-IDF 5.5.4 copies the data into a PBUF_RAM buffer before it queues PPP processing.
• The UART event queue has only eight entries, but the RX task polls the buffered-data length. Queue exhaustion is not the primary concern in this code.

Relation to /json/fxdata

/json/fxdata is a streamed chunked response. It produces more response/ACK activity than a small response. The low mailbox limit and input flush can therefore show up more often on this endpoint.

TCP normally recovers from lost PPP frames. Thus, this PPP code more naturally causes stalls, retransmissions, timeouts, or failed Fetch requests. It does not by itself prove deterministic HTTP response truncation.

The reported result still matters: changing /json/fxdata to a known-length response fixed the visible problem. That indicates response framing or server-response timing is also relevant. The PPP code is a credible amplifier and should not be excluded as a root cause.

Recommended checks:

• Remove all uart_write_bytes() diagnostic output from the PPP UART.
• Count ERR_MEM results from the PPP input path. Enable CONFIG_ESP_NETIF_RECEIVE_REPORT_ERRORS for this test.
• Record each uart_flush_input() occurrence.
• Test /json/fxdata with the flush disabled or with a larger RX ring and a larger CONFIG_LWIP_TCPIP_RECVMBOX_SIZE.
• Capture PPP traffic on the host and compare TCP retransmissions for the chunked and Content-Length variants.

_{You are interacting with an AI system.}

[aenertia]

Noting that the PPP patches have interactions I haven't fully untangled yet — the root cause here may be in the transport layer rather than AsyncWebServer. Leaving the fork analysis for reference but treating the mechanism as unconfirmed until I have better isolation.