[SERVER-66273] Add CleanupConcurrencyWorkloads hook to simulate_crash_concurrency_replication.yml Created: 06/May/22 Updated: 29/Oct/23 Resolved: 09/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Yujin Kang Park | Assignee: | Yujin Kang Park |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Execution Team 2022-05-16 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 35 | ||||||||||||
| Description |
|
Usually an FSM workload provides the database and collection to use, and cleans up automatically. The create_database.js test creates and drops databases and collections, because that's the point of the test. The issue is that the databases are not always always dropped, and on burn-in runs where the test is run multiple times, subsequent runs end up failing due to already existing database/collection. |
| Comments |
| Comment by Githook User [ 09/May/22 ] |
|
Author: {'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}Message: |
| Comment by Max Hirschhorn [ 06/May/22 ] |
|
Good question - my expectation is every concurrency*.yml test suite would use the CleanupConcurrencyWorkloads hook. I'm not familiar enough with the simulate_crash_concurrency_replication.yml test suite to know why it hadn't copy-paste that hook along with the other data consistency checking ones. For completeness, I'll mention it's possible to compose resmoke hooks by calling other hooks in Python too. The PeriodicKillSecondaries hook does this for running ValidateCollections, CheckReplDBHash, and CheckReplOplogs. However, I think it'll be easier here to add CleanupConcurrencyWorkloads to the list in the YAML than to try and change any of the Python code. |
| Comment by Daniel Gottlieb (Inactive) [ 06/May/22 ] |
|
Dumb question max.hirschhorn@mongodb.com: if concurrency workloads aren't meant to be responsible for dropping their own state, under what circumstances should an FSM workload/suite not utilize the CleanupConcurrencyWorkloads hook? |
| Comment by Yujin Kang Park [ 06/May/22 ] |
|
Hey max.hirschhorn@mongodb.com, thanks for the info! I thought the framework only handled the databases created by the framework itself. |
| Comment by Max Hirschhorn [ 06/May/22 ] |
|
Hey yujin.kang@mongodb.com, the concurrency framework code is meant to clean up the data written by the FSM workloads. The FSM workloads aren't meant to be directly responsible for dropping their own state. It seems like the simulate_crash_concurrency_replication.yml test suite is missing the CleanupConcurrencyWorkloads hook which the concurrency_replication.yml suite uses. CC gregory.wlodarek@mongodb.com, daniel.gottlieb@mongodb.com |