Summary

The URI options spec specifies the socketTimeoutMS option as "non-negative integer; 0 means no timeout". Setting socketTimeoutMS to 0 does not have that effect in libmongoc.

Environment

Tested using libmongoc 1.29.0

How to Reproduce

I was able to reproduce this by running a long aggregation pipeline, which eventually resulted in a socket timeout.

Additional Background

Negative values for socketTimeoutMS were fixed in CDRIVER-4781, which also raised the question whether 0 actually means unlimited in libmongoc. At least for _mongoc_stream_socket_writev, this is definitely not the case. The get_expiration function calculates the expiration using the provided timeout_msec, which is as follows:

• For any timeout_msec < 0, it returns -1
• For any timeout_msec == 0, it returns 0
• For other values, it adds the timeout_msec to the monotonic BSON time to get the expiration time

This expire_at value is later checked in mongoc_socket_sendv. There, an expire_at value of 0 or greater is compared to the computed expiration time. This means that at least for that check, "unlimited" is represented by a value of -1, which is no longer possible after the fix introduced in CDRIVER-4781. A value of 0 essentially means "time out immediately when checking", as that will always be smaller than the monotonic BSON time (and if it ever isn't, I'm hopefully not around to deal with it).

IMO, libmongoc should be changed to have 0 actually mean "unlimited", while leaving the behaviour of -1 untouched and eventually removing it entirely, especially as timeout_msec is corrected to a positive value in mongoc_stream_writev.