Thanks for this fine report!

I believe I never implemented any action in the event of an error being returned from these callbacks partly because I couldn't make up my mind on what exactly the correct course of action would be when one of those callbacks return error. That's also why the documentation doesn't say anything about it. Another reason would probably be that applications very rarely actually return error there so this omission has remained ignored/forgotten...

I guess the only sensible way to treat these errors is to immediately cancel the transfer, since a transfer done with an application that is setup to use these callbacks cannot really be handled correctly anymore from that point.

Ah right, it needs to cancel all transfers currently in progress because these callbacks are per multi-handle, not per transfer.

I think perhaps the slightly trickier part with this behavior is that it will take down all currently active transfers but once they're all closed down, it should probably be possible to start over and add new connections to the multi handle again.

I'll try to make a test case for all this...

I've done some testing and had success with the following approach:

• when the timer callback fails, the application sets an internal flag so it can later call curl_multi_socket_action with CURL_SOCKET_TIMEOUT from the event loop. It doesn't seem like curl needs to take any action other than document the workaround so that application developers can implement it;
• when the socket callback fails, call curl_multi_socket_action for the fd in question with CURL_CSELECT_ERR. This is something that curl might be able to do internally when the callback returns -1. I observed that the callback got called with CURL_POLL_REMOVE as expected and the state machine worked just fine to free resources associated with that transfer.

I don't believe curl needs to always cancel all transfers, since:

• the socket callback is per fd so only that fd's transfers need to be cancelled;
• there's a workaround for timeout callback, albeit not ideal. Maybe let the application decide in this case? E.g.: if callback errors out, it can:
  • return 0 and do the flag/poll thing;
  • return -1 and the whole multi handle gets aborted.
    Does that make any sense?

when the timer callback fails

If the application wants to avoid causing all transfers to fail, it can do that by not returning error from the callback and it can then opt to handle it using a work-around as you describe. I don't think that's a way we should encourage though, as it will be complicated and error-prone. The timer is meant to be able to expire many times during a single transfer, and a work-around then needs to replace all of them artificially.

the socket callback is per fd so only that fd's transfers need to be cancelled;

The specific fd is not always unique for one or a subset of transfer, it can also be the name resolving fd for example which is used by (almost) all transfers. So, yes, while we could make libcurl not fail all transfers for socket cb failure, I don't think think it is worth the trouble to support that.