In mongodb/mongo-php-library#562, a user reported an issue executing a Collection::find() operation in PHPLIB. Because the library explicitly assigns the collection's read preference on the query, it triggered the following code path in _mongoc_cursor_new_with_opts():
if (_mongoc_client_session_in_txn (cursor->client_session)) { if (!IS_PREF_PRIMARY (user_prefs)) { bson_set_error (&cursor->error, MONGOC_ERROR_CURSOR, MONGOC_ERROR_CURSOR_INVALID_CURSOR, "Read preference in a transaction must be primary"); GOTO (finish); } if (user_prefs) { bson_set_error ( &cursor->error, MONGOC_ERROR_CURSOR, MONGOC_ERROR_CURSOR_INVALID_CURSOR, "Cannot set read preferences after starting transaction"); GOTO (finish); }
The first check for a non-primary read preference is consistent with _mongoc_client_command_with_opts() and mongoc_cmd_parts_assemble(), but the second conditional only exists in this function. I don't believe it serves a purpose, as a primary read preference should be permitted at this point.
Note: I realize that it's a bit redundant for PHPLIB to add a read preference to a query if we're not communicating with mongos, since we would have already done server selection by this point. That is likely be something we can refactor independently of this issue.
- is depended on by
-
PHPC-1236 Upgrade libmongoc to 1.11.1
- Closed
- related to
-
PHPC-1251 Upgrade libmongoc to 1.12.0
- Closed
-
PHPLIB-375 Consider omitting readPreference option in commands/queries to non-sharded topologies
- Backlog
- links to