Info

When applying read concern, a user specified read concern with an empty object (ie. readConcern: {}) means two different things. If specified by an internal client, this means "use the implicit default" while if specified by a user, this means "apply the cluster-wide default". There is a problem with the internal transaction API, though, because commands run via the internal transaction API do not count as internal client commands though the caller generally expects that behavior. This means that an internal command run via the internal transaction API will use the cluster wide default rather than the implicit default. Prior to SERVER-111031, this was not an issue because (1) all internal transactions in replica sets specify a non-empty read concern and (2) all non-mongoS commands in sharded clusters used the implicit default. SERVER-111031 changed (2) though, and so now the places in sharded clusters where we specify readConcern: {} and expect readConcern: {level: "local"} are now problematic when a cluster wide default is set (as you will get the default, not local). This ticket is to address the places in sharded clusters where the read concern is being specified as empty using the transaction API. Other tickets will be filed to enforce this, but as this will need backported that will not be handled here.

Top User Comments

xgen-internal-githook commented on Mon, 5 Jan 2026 15:21:17 +0000: Author: {'name': 'Allison Easton', 'email': 'allison.easton@mongodb.com', 'username': 'allisoneaston'} Message: SERVER-116129 Internal transactions should never specify empty read concern (#45834) GitOrigin-RevId: 0995e5615ead32eed632fc1a1707597731aa6452 Branch: master https://github.com/mongodb/mongo/commit/7194b4b76fdf02cc9f0d8eeab1c3d7645757957a

Steps to Reproduce