AsyncAbstractResponse: chunked responses close connection before ACKs in RESPONSE_WAIT_ACK

[aenertia]

AsyncAbstractResponse: chunked responses close connection before ACKs in RESPONSE_WAIT_ACK

In AsyncAbstractResponse::_ack() (WebResponses.cpp), the RESPONSE_WAIT_ACK exit condition is:

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

On the chunked path, sendChunked() sets _chunked=true and _sendContentLength=false. The !_sendContentLength term is unconditionally true, so RESPONSE_WAIT_ACK exits immediately on the next _ack() call regardless of _ackedLength >= _writtenLength. close() fires as soon as the final zero-length chunk is written to the lwIP send buffer — not when it is ACKed.

On fast WiFi the write-to-ACK gap is short enough that this doesn't matter in practice. On slow transports (PPP/UART, congested WiFi with retransmissions) the gap is large enough that the connection closes before the tail of the payload drains, truncating the response on the client.

Your fork addressed this in 747223f02f8e by dropping the ACK wait entirely and relying on AsyncWebServerRequest::_onAck for graceful close. This issue documents the root cause for the benefit of other forks still carrying the buggy condition, and to ask whether a minimal targeted fix might be worth upstreaming to me-no-dev as well.

State across active forks (as of August 2026)

Fork	AsyncAbstractResponse WAIT_ACK condition	Status
me-no-dev AsyncAbstractResponse	!_sendContentLength || _ackedLength >= _writtenLength	Buggy
me-no-dev AsyncBasicResponse lines 320-323	_ackedLength >= _writtenLength	Fixed — inconsistent within same file
mathieucarbou AsyncAbstractResponse	!_sendContentLength || _ackedLength >= _writtenLength	Buggy
Aircoookie ac44e32 (WLED fork)	!_sendContentLength || _ackedLength >= _writtenLength	Buggy
ESP32Async 747223f02f8e	Unconditional _state = RESPONSE_END	Addressed — different approach

Minimal fix (for forks not adopting the ESP32Async lifecycle refactor)

Match AsyncBasicResponse — remove the !_sendContentLength shortcut:

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

Context

Discovered while investigating truncated /json/fxdata responses on PPP/UART and congested WiFi in wled/WLED#5808. That PR works around it at the application level by switching from sendChunked() to request->send() with a pre-computed Content-Length (_sendContentLength=true), which gates RESPONSE_WAIT_ACK correctly. The workaround is unaffected by whether this is fixed in the library.

[willmmiles]

close() fires as soon as the final zero-length chunk is written to the lwIP send buffer — not when it is ACKed.

This is the correct behaviour. When close() is called, LwIP holds the connection alive until any queued bytes are acked, as is required of any conforming TCP implementation. There is no need for AsyncWebServer to continue to hold a connection handle after all bytes of a chunked transfer are send() as we no longer have any work to do.

[aenertia]

You're right -- I had the wrong mental model. tcp_close() initiates graceful close and lwIP queues FIN after the send buffer drains, so the early close() call from ESPAsyncWebServer isn't the problem.

The truncation I observed on PPP/UART and congested WiFi was real -- I can reproduce it consistently with sendChunked() and not with request->send() + Content-Length. But if it's not the RESPONSE_WAIT_ACK early exit, what is it? Is there a known failure mode on slow links with chunked responses, or should I be looking at the PPP/AsyncTCP interaction more carefully?

[aenertia]

After poking my harness to look at the delta between 747223f and what WLED is carrying, I think the actual issue may be that the old path counts bytes accepted into AsyncTCP's internal queue rather than bytes that have made it into the lwIP send buffer. On slow links those can diverge enough that the response lifecycle concludes while data is still in transit through AsyncTCP's internals. Your rewrite closes that gap. Would that match your understanding of the bug?

[willmmiles]

AsyncTCP doesn't have an "internal queue" on the send path, it's a thin wrapper around LwIP.

[aenertia]

Following up — the truncation turned out to be sendChunked callback returning 0 instead of RESPONSE_TRY_AGAIN when the available buffer was too small to fit a single item. ESPAsync's behaviour is correct; we weren't speaking the callback contract. Thanks @willmmiles for the corrections on tcp_close() and AsyncTCP internals — those are what eventually pointed us at the actual issue. Details in wled/WLED#5808.