Curl snagging

[cjen1-msft]

Two warnings were seen recently during testing, EBADF from the libuv polling of the socket and CURL_POLL_IN during shutdown.

When libuv receives a POLLERR from its epoll it surfaces that as EBADF in the poll callback.
This can happen when the other side of a tcp connection abruptly disconnects.
Previously we FAIL logged this and otherwise ignored it, now we pass the error back to curl (CURL_CSELECT_ERR), and INFO log it.

Next, supposing there are several requests to the same address, curl will cache and reuse the socket for this.
However this means that come shutdown the socket may still be alive.
When curl_multi_cleanup is called, this causes the socket to try to poll for any remaining data or a disconnect via CURL_POLL_IN, before immediately calling CURL_POLL_REMOVE.
In this case we simply want curl to shutdown the relevant sockets and thus do not register the new polling.

[achamayou]

When libuv receives a POLLERR from its epoll it surfaces that as EBADF in the poll callback.

@cjen1-msft I can't seem to find a source for this, could you link one please?

[cjen1-msft]

When libuv receives a POLLERR from its epoll it surfaces that as EBADF in the poll callback.

@cjen1-msft I can't seem to find a source for this, could you link one please?

Here is the related libuv issue:
libuv/libuv#3796

And the corresponding bit of libuv documentation:
https://docs.libuv.org/en/v1.x/poll.html#c.uv_poll_start

The situation is a unfortunately vague as libuv only says that something has gone wrong and will never fire an event on that socket again (unless you call uv_start_t again).
And libcurl doesn't give strict semantics on how it responds to CURL_CSELECT_XXX.

So on the curl side we need to notify it of the error and then from staring at the code on their side it seems to do some health checks on the socket before in this case firing a removal event.
If the curl side were instead to reschedule (CURL_POLL_INOUT) then that would end up re-calling uv_start_t on the fd which is also fine.