Quoting my comment from CDRIVER-1329:

mongoc_find_and_modify_opts_set_max_time_ms() accepts a uint32_t and the options struct internally tracks max_time_ms as uint32_t. In mongoc_collection_find_and_modify_with_opts(), the value is appended with BSON_APPEND_INT32. We should be able to cast the value as an int64_t and append as a 64-bit BSON integer, which would remove the risk of UINT32_MAX turning into INT32_MIN.

Similarly, mongoc_cursor_set_max_await_time_ms() and mongoc_cursor_get_max_await_time_ms() use uint32_t but store the value as an int64 in the cursor's options bson_t. This effectively limits the value to UINT32_MAX. However, users could theoretically pass a larger non-negative 64-bit integer as "maxAwaitTimeMS" via the find options and ignore the getter's limitation. That said, we still have a problem in mongoc_cursor_prepare_getmore_command(), as it uses the getter (which will cast down the original int64_t) and _also uses bson_append_int32 to append, which also carries the risk of UINT32_MAX turning into INT32_MIN.

Correcting the usage of uint32_t will break ABI (hence CDRIVER-1329 targeting 2.0) but we should be able to fix the internal appending behavior.

If users of mongoc_collection_find_and_modify_with_opts() need to specify a larger "maxTimeMS" value, they can add it directly to the extra opts bson_t and avoid using mongoc_find_and_modify_opts_set_max_time_ms() altogether.

There is no limitation with mongoc_collection_find_with_opts() supporting large "maxTimeMS" values since users supply their own bson_t for options. "maxAwaitTimeMS" will be limited to uint32_t since it is set via a function after the cursor is created, so the documentation should likely be updated to note this limitation. That said, UINT32_MAX should be sufficient for all practical use cases.