[SERVER-79952] FLE2 batched inserts doesn't obey the stmtId contract for auxiliary operations in retryable internal transactions Created: 11/Aug/23  Updated: 21/Aug/23

Status: Open
Project: Core Server
Component/s: Queryable Encryption
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Security
Operating System: ALL
Sprint: Security 2023-08-21
Participants:

 Description   

QE/FLE2 batched inserts only respect the stmtId of the first statement from an insert request and then increment it freely for each generated writes (instead of using kUninitializedStmtId/-1 for the auxiliary writes like other retryable internal transaction use cases).

So for example, an insert request with two statements (op1, op2) with stmtIds [1, 3] will end up using stmtIds[1, 2, 3] for the op1 (and its metadata writes) and stmtIds[4, 5, 6] for op2 (and its metadata writes). I haven't looked deep enough to tell whether this is actually a bug that would affect retryability from the user perspective. But this seems to violate how stmtIds are supposed to be handled in retryable internal transactions. More investigation needed to determine if this would manifest as a bug.


Generated at Thu Feb 08 06:42:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.