#6737 add metric to track how long nodes are stuck blocked by max parallelism being reached Pull request opened by pvditt ## Why are the changes needed? Transition latency includes the time a node waits for max parallelism. ## What changes were proposed in this pull request? Adding a new metric to get some estimate as to how long nodes are waiting for slots to free up for a given execution isn't a great solution to the above problem, however, without adding a new field to node status, this might be the best work around. This new metric w/ it's current implementation also has the issue of getting updated on each successive loop for a given node. ## How was this patch tested? ran locally in sandbox ### Labels Please add one or more of the following labels to categorize your PR: • added: For new features. • changed: For changes in existing functionality. • deprecated: For soon-to-be-removed features. • removed: For features being removed. • fixed: For any bug fixed. • security: In case of vulnerabilities This is important to improve the readability of release notes. ### Setup process ### Screenshots ## Check all the applicable boxes • I updated the documentation accordingly. • All new and existing tests passed. • All commits are signed-off. ## Related PRs ## Docs link https://bito.ai#summarystart| ### Summary by Bito • This pull request introduces a new metric, 'ParallelismWaitLatency', in the executor to track how long nodes are waiting for execution slots due to max parallelism being reached. • The implementation serves as a workaround to better estimate node latency in a parallel execution context without altering the node status structure. • The changes aim to provide insights into node wait times. • Overall, this update introduces a new metric in the executor related to node execution latency. flyteorg/flyte