Error: Cannot set read preferences after starting transaction

[sandrokeil]

I don't explicitly set a read preference but it looks that this library sets always read preference primary for each query if not specified. This results in the error Cannot set read preferences after starting transaction.

Here is an example which fails:

$client = new Client();
$collection = $client->selectCollection('mydb', 'test');
$session = $client->startSession();
$session->startTransaction(
    [
        'readConcern' => new \MongoDB\Driver\ReadConcern('snapshot'),
        'writeConcern' => new \MongoDB\Driver\WriteConcern(\MongoDB\Driver\WriteConcern::MAJORITY),
    ]
);

$options = [
    'session' => $session
];

$collection->findOne([], $options); // -> Exception

How can I read data from a collection inside a transaction?

[jmikola]

Thanks for the report. This looks to be a libmongoc bug, which I've reported in CDRIVER-2744 and submitted a PR for in mongodb/mongo-c-driver#517. It looks like this can be addressed in libmongoc's upcoming 1.11.1 release, for which we will likely publish a new PHPC release for those using the bundled version of libmongoc instead of system libraries. I've created PHPC-1236 to track that.

Additionally, I believe we can make an improvement to PHPLIB by not sending an explicit read preference option on commands/queries unless we're communicating with a sharded cluster (where transactions are not even supported in 4.0). I've opened PHPLIB-375 to track that. While this won't fix the libmongoc bug, it would allow PHPLIB to work around it.

Please watch both PHPC-1236 and PHPLIB-375 for updates (or CDRIVER-2744 if you've configured the PHP extension to use libmongoc and libbson as system libraries). I expect that any one of those issues will resolve this for you.

---

As for why we didn't catch this sooner, most of the driver's current transaction tests exist in the extension and our PHPLIB test coverage is currently through documentation examples (PHPLIB-350), which double as integration tests. Unfortunately, none of those tests used Collection::find(). We do have plans to implement the full suite of tests from the transactions spec. This is being tracked in PHPLIB-365, which is one of a number of follow-up tasks for MongoDB 4.0 support.

In the meantime, I will write up a regression test for this so we have something in PHPLIB before implementing the entire transaction spec's test suite. I'll cross-reference that with this issue when I have a PR and also associate it with the planned improvements in PHPLIB-375.

[sandrokeil]

I'm glad to help. One question, why is it a problem so set the same read preference in the transaction, in this case primary, more than once? The read preference doesn't change and primary is the default.

For my understanding, it should only be a problem, if the read preference changed, but not if the same read preference is set more than once within a transaction. But maybe it's a implementation detail.

[jmikola]

One question, why is it a problem so set the same read preference in the transaction, in this case primary, more than once?

For starters, the "Cannot set read preferences after starting transaction" error message is entirely due to a bug in libmongoc.

If you look at the code I cited in CDRIVER-2744, you'll see two conditional that check the read preference. The first check is for "Read preference in a transaction must be primary", which is correct. Transactions do allow a read preference, which can be set in either the transaction's options when it is started or later at a per-operation level (for those drivers that allow that, such as PHP). In MongoDB 4.0, transactions can only be executed on a primary member of a replica set, hence the reason for that first conditional. The second conditional, which checks that no read preferences have been provided for the individual operation, is a mistake.

The transaction spec's readPreference section explains this in more detail.

The "RP must be primary" check happens in a few other code paths in libmongoc, including generic command execution. The bug due to the second conditional was only present in one code path, which is used for basic queries (e.g. Collection::find()). I don't believe you would have encountered this by doing an aggregation.

For my understanding, it should only be a problem, if the read preference changed, but not if the same read preference is set more than once within a transaction.

You're correct. The driver should only report an error if a non-primary read preference is used (in either the initial transaction options or at the operation level).

[sandrokeil]

I don't believe you would have encountered this by doing an aggregation.

Just want to let you know that if I run $collection->aggregate([], $options); it results in the same issue.

[jmikola]

Just want to let you know that if I run $collection->aggregate([], $options); it results in the same issue.

Can you double-check that? I added regression tests for aggregate() in #564 and didn't see any test failures (only for find()). The following standalone script also runs just fine against a single-node replica set running on 127.0.0.1:27017:

<?php

require 'vendor/autoload.php';

$client = new \MongoDB\Client;

$client->test->dropCollection('gh562', ['writeConcern' => new \MongoDB\Driver\WriteConcern('majority')]);
$client->test->createCollection('gh562', ['writeConcern' => new \MongoDB\Driver\WriteConcern('majority')]);
$collection = $client->test->gh562;

$session = $client->startSession();
$session->startTransaction();

try {
    $collection->insertMany(
        [['x' => 1], ['x' => 2], ['x' => 3]],
        ['session' => $session]
    );

    $cursor = $collection->aggregate(
        [['$match' => ['x' => ['$lt' => 3]]]],
        ['session' => $session]
    );

    var_dump($cursor->toArray());

    $session->commitTransaction();
} catch (Exception $e) {
    $session->abortTransaction();
    throw $e;
}

If I change this script to pass an explicit "primary" read preference in the aggregate() options, it also executes without error. Passing an explicit non-primary read preference (e.g. "secondaryPreferred") results an expected exception: "Read preference in a transaction must be primary".

I'm not sure how you would ever see a "Cannot set read preferences after starting transaction" error here, since libmongoc was only reporting that error for the find() code path.

[sandrokeil]

You're right, sorry for the confusion.

[jmikola]

CDRIVER-2744 has been fixed in libmongoc 1.12. PHPC-1251 upgrades our libmongoc dependency, so this should be resolved in the extension's upcoming 1.5.2 release.