[SERVER-53811] abortTransaction on mongos fails with BSON field 'abortTransaction.recoveryToken' is an unknown field Created: 14/Jan/21  Updated: 29/Oct/23  Resolved: 20/Jan/21

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: 4.9.0-alpha2

Type: Bug Priority: Major - P3
Reporter: Shane Harvey Assignee: Moustafa Maher
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
causes PYTHON-2492 Test Failure - test_transactions_retr... Closed
is caused by SERVER-52547 Convert commitTransaction and abortTr... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Sprint: Repl 2021-01-25
Participants:

 Description   

Running abortTransaction on 4.9 mongos with a recoveryToken results in the following error:

{"ok": 0.0, "errmsg": "BSON field 'abortTransaction.recoveryToken' is an unknown field.", "code": 40415, "codeName": "Location40415", "$clusterTime": {"clusterTime": {"$timestamp": {"t": 1610655278, "i": 9}}, "signature": {"hash": {"$binary": {"base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "subType": "00"}}, "keyId": 0}}, "operationTime": {"$timestamp": {"t": 1610655278, "i": 9}}}

The full command was:

{"abortTransaction": 1, "recoveryToken": {"recoveryShardId": "demo-set-0"}, "writeConcern": {"w": "majority"}, "lsid": {"id": {"$binary": {"base64": "fKTNnHJNRmqnwO4wxtVj1g==", "subType": "04"}}}, "txnNumber": 1, "autocommit": false, "$clusterTime": {"clusterTime": {"$timestamp": {"t": 1610655278, "i": 9}}, "signature": {"hash": {"$binary": {"base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "subType": "00"}}, "keyId": 0}}, "$db": "admin", "$readPreference": {"mode": "primary"}}

The server version:

mongos version v4.9.0-alpha-1297-g0edda21
Build Info: {
    "version": "4.9.0-alpha-1297-g0edda21",
    "gitVersion": "0edda21e200d7d7186f236e54bb331c402cdeb1a",
    "modules": [
        "enterprise"
    ],
    "allocator": "system",
    "environment": {
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

This is unexpected because drivers send recoveryToken on both commitTransaction and abortTransaction as decided in SERVER-39692 (and implemented in DRIVERS-635).



 Comments   
Comment by Moustafa Maher [ 20/Jan/21 ]

recoveryToken has been addd as accepted optional field for abortTransaction 

Comment by Githook User [ 20/Jan/21 ]

Author:

{'name': 'Moustafa Maher', 'email': 'm.maher@10gen.com', 'username': 'moustafamaher'}

Message: SERVER-53811 add recoveryToken as input field to abortTransaction
Branch: master
https://github.com/mongodb/mongo/commit/7bfed517d2545820e41e05f1855da254de673e28

Comment by Moustafa Maher [ 19/Jan/21 ]

shane.harvey I have checked, and no Server doesn't run the driver tests, but it will be ran after the code is committed to master on the driver side.

Comment by Shane Harvey [ 19/Jan/21 ]

m.maher, does the server implement the driver transaction spec tests?  Specifically these 4 tests started failing because of this change: https://github.com/mongodb/specifications/blob/d05cbdf/source/transactions/tests/retryable-abort.yml#L1017-L1311

You can see the test failures in PYTHON-2492.

Comment by Shane Harvey [ 19/Jan/21 ]

m.maher, please refer to https://github.com/mongodb/specifications/blob/master/source/transactions/transactions.rst#server-commands :

The commitTransaction server command has the following format:

{
    commitTransaction : 1,
    lsid : { id : <UUID> },
    txnNumber : <Int64>,
    autocommit : false,
    writeConcern : {...},
    maxTimeMS: <Int64>,
    recoveryToken : {...}
}

The abortTransaction server command has the following format:

{
    abortTransaction : 1,
    lsid : { id : <UUID> },
    txnNumber : <Int64>,
    autocommit : false,
    writeConcern : {...},
    recoveryToken : {...}
}

Comment by Kaloian Manassiev [ 15/Jan/21 ]

Assigning it to the Replication Team's backlog. CC m.maher.

Comment by Kaloian Manassiev [ 15/Jan/21 ]

I am also surprised it is not failing tests like this one which explicitly send the recovery token.

Comment by Shane Harvey [ 14/Jan/21 ]

I suspect this was caused by SERVER-52547.

Generated at Thu Feb 08 05:31:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.