Skip to content

Conversation

@mathieucarbou
Copy link
Member

@mathieucarbou mathieucarbou commented Aug 1, 2025

This PR fixes a bug introduced in PR #79.

discarded callback must also be called when abort() is called.

Ref: ESP32Async/ESPAsyncWebServer#253

@mathieucarbou
Copy link
Member Author

CC @willmmiles @gluca

Comment on lines +928 to +931
if (_discard_cb) {
// _pcb was closed here
_discard_cb(_discard_cb_arg, this);
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@willmmiles: no sure if this block should be within the if (_pcb) { block or not. If yes, then maybe the same is true for close also and the latter should be updated too ?

What do you think ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#79 moved the _pcb check in AsyncClient::close() to be done just once in the LwIP context in _tcp_close_api, which then returns whether or not the dispose callback needs to be run after checking _pcb and the queue contents. The key reason is that _pcb could be nullptr while there's still a FIN or ERROR event pending, so even if it is, we need to purge the queue. I didn't want to replicate the purge code just to avoid the LwIP lock, though that would be a technically valid approach.

@willmmiles
Copy link

willmmiles commented Aug 1, 2025

Ah, I'd noticed that abort() didn't seem to call the discard callback, so I left it that way on the assumption that was the intended semantic.

... but the trick was that tcp_abort() actually calls the tcp_err() callback if it's still registered on that _pcb. So the mistake was adding _reset_tcp_callbacks in _tcp_abort_api, which would instead stop it from adding an error event to the async queue.

Offhand, I'd probably recommend restoring the original semantics, just in case someone depends on abort() triggering the dispose callback on the async task. I can send a quick PR later tonight.

@mathieucarbou
Copy link
Member Author

Replaced by #82

@mathieucarbou mathieucarbou deleted the fix-79 branch August 2, 2025 08:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants