Description
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.
Attachments
Issue Links
- 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