The sessions spec says:

When an operation using a session returns a cursor, all subsequent GETMORE commands for that cursor MUST be run using the same session ID.

mongoc_cursor_t does this when an explicit session is passed in "opts", but when it uses an implicit session this behavior isn't guaranteed.

Our tests passed by accident, because the session pool is LIFO, and in the single-threaded case it usually only has one lsid anyway:

cursor = mongoc_collection_find_with_opts (...);
mongoc_cursor_next (...); /* acquire and release implicit session */
mongoc_cursor_next (...); /* acquire and release SAME implicit session */

However, if another session were pushed into the pool between the initial "find" and the first "getMore", or between any pair of subsequence getMores, then its new lsid would be used for the next "getMore" instead. If auth is enabled, this will result in a server error code 13, "Cursor session id is not the same as the operation context's session id".