[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: |
|
||||||||||||||||
| 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:
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 |
| 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 |
| Comment by Spencer Brody (Inactive) [ 23/Mar/18 ] |
|
This is related to the work on |
| 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? |