[SERVER-34059] DuplicateKeyError aborts transaction Created: 22/Mar/18  Updated: 06/Dec/22  Resolved: 19/Jun/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-33432 Implicit transaction abort Closed
related to SERVER-34051 Require autocommit:false on all opera... Closed
is related to DOCS-11493 Document which errors abort transactions Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

I'm trying to test how drivers will handle error cases within multi-statement transactions. I perform the following with my prototype of PyMongo that supports transactions:

session = client.start_session()
session.start_transaction()
collection.insert_one({'_id': 1}, session=session)
try:
    collection.insert_one({'_id': 1}, session=session)
except Exception as exc:
    print(exc)
collection.insert_one({'_id': 1}, session=session)
session.commit_transaction()

It appears (based on debugging) that the transaction includes the document {_id: 1} after the first insert, and the second insert not only causes a duplicate key error, it also aborts the transaction. Therefore the third insert succeeds (outside of any transaction), and the commit_transaction fails with code 125, errmsg "Transaction isn't in progress."



 Comments   
Comment by Gregory McKeon (Inactive) [ 19/Jun/18 ]

This is currently not possible to fix in the storage engine.

Comment by A. Jesse Jiryu Davis [ 26/Mar/18 ]

I've opened DOCS-11493 to at least write down all the errors that abort a transaction.

Comment by Siyuan Zhou [ 23/Mar/18 ]

I had a patch last night to allow DuplicatedKey error, but it turns out we cannot.

DuplicatedKey error is checked as a part of a WUOW after the data write, the convention is to uassert and abort the WT transaction. If we keep the WT transaction and reuse it, the document will be preserved in the data table. DuplicatedKey error is just one example. Any index constraints will result in the same issue, e.g. inserting unexpected location format into geo index.

Comment by Spencer Brody (Inactive) [ 23/Mar/18 ]

The latter issue about the third write being performed outside the transaction will be fixed by SERVER-34051

Comment by Spencer Brody (Inactive) [ 23/Mar/18 ]

This is related to the work on SERVER-33432, and can probably be completed concurrently to it. We should have a set of error codes that cause implicit transaction abort, and otherwise we should leave the transaction in place.

Comment by A. Jesse Jiryu Davis [ 22/Mar/18 ]

It's from a server behavior. The driver appears to be doing the right thing: same lsid and txnNumber as the previous inserts, and a stmtId that is one greater. The server has forgotten about the transaction, though, so I guess it thinks this is a retryable write, and it succeeds.

Comment by Andy Schwerin [ 22/Mar/18 ]

It's also worrisome that the server thought the third insert was outside a transaction. Is that from a server or driver behavior?

Generated at Thu Feb 08 04:35:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.