[SERVER-37000] Transactions tests that have knowledge of prepare machinery should live in jstests/core/txns/prepare, which should be blacklisted from sharding suites Created: 05/Sep/18 Updated: 06/Dec/22 Resolved: 17/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | prepare_optional, prepare_testing | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Participants: |
| Description |
|
The jstests/core/txns directory is intended to contain transactions tests that are topology agnostic i.e. tests that would generalize from a single replica set to a sharded cluster. Tests that run 'prepareTransaction' are not topology agnostic i.e. they depend on the fact that they are run against a single replica set, not a mongos. As a consequence of this, any test that runs prepareTransaction and is placed inside jstests/core/txns must then be blacklisted from any sharded transaction suite, e.g. sharded_core_txns. This blacklisting effort is unnecessary since we would never intend to run these tests in sharded passthroughs since the functionality they test is specific to single replica sets. Placing them in jstests/replsets obviates the need to do any blacklisting. Ideally we would move all existing "prepare" tests in jstests/core/txns into jstests/replsets. |
| Comments |
| Comment by Gregory McKeon (Inactive) [ 17/May/19 ] |
|
Given that we now have tags, we won't do this. |
| Comment by William Schultz (Inactive) [ 05/Sep/18 ] |
|
I think I perceive "core" tests differently. I think of them as being the most generic tests of the database we have i.e. ones that exercise features common to any database configuration or topology. For example, "can I insert a document and read it back". Or, similarly, testing any standard MongoDB CRUD operation. Originally, I perceived transactions as (eventually) being one of the core database features. I acknowledge that there may be certain "core" features that are not fully generic (e.g. don't work in a sharded cluster), but my intuition is that most tests that get added to the "core" suite do not require special blacklisting. That is, needing to blacklist a core test from a particular suite is the exception, not the rule. I see your point about the prepare tests running in any suite, though. (I'm assuming that you would be thinking about initial sync passthroughs, as one example). I think making a sub-directory that is prepare specific and excluding that directory by default from any non-replica set transactions suites may be a good solution. We could perhaps then view 'prepare' as a "core" replica set feature i.e. something that should work correctly in any replica set, letting all other configuration parameters vary. |
| Comment by Judah Schvimer [ 05/Sep/18 ] |
|
I personally think of 'core' tests as being less topology-agnostic and moreso topology-constant. They do not change the topology, but there are some that they may not apply to (and so we blacklist them). |
| Comment by Judah Schvimer [ 05/Sep/18 ] |
|
I would lean towards a jstests/core/txns/prepare/ directory potentially. The benefit of having them where they are is that they will be run in any suites that run with a single replica set, which will be useful once we make prepared transactions recoverable. |
| Comment by William Schultz (Inactive) [ 05/Sep/18 ] |
|
I recognize that there may already be some other tests in jstests/core/txns that do not abide by the "topology agnostic" rule (e.g. see the blacklist in sharded_core_txns), but the prepare related tests are certainly a large portion of these. |