[SERVER-48217] Allow the background validation hooks number of jobs or frequency to be modified with resmoke for local development Created: 14/May/20  Updated: 06/Dec/22  Resolved: 08/Jun/20

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

Type: New Feature Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Won't Do Votes: 0
Labels: tig-resmoke, undo-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Assigned Teams:
Server Tooling & Methods
Participants:
Linked BF Score: 19

 Description   

We've been seeing a rise in the number of build failures related to validation rise recently. Reproducing these failures is often very time-consuming. For example, I had a build failure related to validation failing that I wasn't able to reproduce until I changed the hook script to run more validation threads concurrently.

It would be a useful feature to be able to change the number of validation jobs or their frequency for build failure reproduction from the resmoke invocation.



 Comments   
Comment by Brooke Miller [ 08/Jun/20 ]

STM doesn't have immediate plans to work on this. Please feel free to re-open if needed.

Comment by Robert Guo (Inactive) [ 21/May/20 ]

Per offline discussions with Gregory, I think we should look into adding test coverage for stressing validate(). The hook is meant to be lightweight and ideally not catch issues that only shows up when there is resource contention. A concurrency workload that calls validate() would be a good way to achieve that.

Comment by Gregory Wlodarek [ 18/May/20 ]

brooke.miller, sure I've attached the build failure.

Comment by Brooke Miller [ 18/May/20 ]

Hey gregory.wlodarek, could you provide the link to the BF that you mentioned above? We're working with Undo to make many Evergreen failures recorded so that they don't need to be reproduced. This seems like a good candidate to test this, once we finish PM-1757, which will be completed shortly.

Generated at Thu Feb 08 05:16:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.