[SERVER-34294] Extend multi_statement_transaction_commit_order.js FSM workload to check consistency periodically Created: 04/Apr/18  Updated: 18/Apr/18  Resolved: 18/Apr/18

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

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Max Hirschhorn
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-34293 Add FSM workload for testing atomicit... Closed
Related
Sprint: TIG 2018-04-23
Participants:

 Description   

A new state function should be added to the multi_statement_transaction_commit_order.js FSM workload that checks there is both (1) a consistent order of elements in the "order" array and (2) exactly nDocs containing that element. The read concern level to use when starting the transaction can be varied because the changes from SERVER-34073 should cause them to all be upconverted and satisfied by "snapshot" anyway.



 Comments   
Comment by Spencer Brody (Inactive) [ 17/Apr/18 ]

sgtm

Comment by Max Hirschhorn [ 17/Apr/18 ]

We'll definitely do more testing work when we change the read concerns to have different meanings that I'm inclined to just revisit this work under a future SERVER ticket.

Comment by Judah Schvimer [ 17/Apr/18 ]

Since all transaction read concerns up-convert to "snapshot", I don't think doing that would add any extra coverage currently, though as we change the semantics around those other read concerns, adding them to the workload would definitely be good.

Comment by Max Hirschhorn [ 16/Apr/18 ]

spencer, judah.schvimer, the changes from 239f4fa as part of SERVER-34293 already periodically check the commit order and number of documents affected by the transaction via the $config.states.checkConsistency() state function. The only work I could think to do on this ticket would be to vary the readConcern we're specifying when starting the transaction. Given the targeted testing that's been added as part of SERVER-34073, I don't think there's a lot of value in changing the FSM workload to do this and am inclined to close this ticket as a duplicate of SERVER-34293. Thoughts?

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