[SERVER-52643] For _gen tasks, store configuration per execution Created: 15/Oct/20  Updated: 27/Oct/23  Resolved: 27/Oct/23

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

Type: Bug Priority: Trivial - P5
Reporter: Lydia Stepanek (Inactive) Assignee: [DO NOT ASSIGN] Backlog - Decision Automation Group (DAG) (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Decision Automation Group
Participants:
Linked BF Score: 0

 Description   

When generating tasks, we used to generate multiple configurations per execution of the _gen task. Recently there was an issue where the different executions of the _gen task resulted in a different number of execution tasks being generated, but the configuration was shared across executions, so an error occurred (see linked BF).

We should probably go back to generating different configurations for different executions.



 Comments   
Comment by David Bradford (Inactive) [ 30/Jul/21 ]

This is still a potential risk, but we have shrunk the window where it might occur down with the changes to generate tasks at the build variant level.

Comment by Brooke Miller [ 14/Jul/21 ]

Re-flagging for Triage since the Epic this belonged to (PM-1911) is being Closed as Won't Do.

Comment by David Bradford (Inactive) [ 06/Nov/20 ]

After running a patch build for this change, we realized that there is an edge-case that can lead to issues. Since the parent and child tasks do not share the same execution, there is a chance that the parent task gets restarted before generated tasks and on the second execution, it will generate the first execution of the child tasks. This leads to a mismatch of the executions. So, we likely need a way to pass some identifier of the generated configuration to the created tasks to make progress on this.

Given that the issue this is meant to resolve is relatively rare (it depends on a strange race being hit in evergreen), we are planning on pushing this change off while we rethink the solution.

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