The approach that we have currently implemented processes every build in a build chain (similarly to how other providers send us webhook first when a job finishes and then when a pipeline finishes). Based on the discussion, there might be issues in which the same build will be running for 2 different build chains, as we might end up with different composite builds for the same build (one for each chain).
A different approach (that they suggested and its implemented with this PR) would be to only process the final composite build of a chain (ignoring all the builds before) and retrieve all its dependencies (previous builds for the chain) when processing it (and sending all the webhooks together). This will avoid the race conditions and it will make the implementation easier (we only need to traverse the chain graph once from right to left, which is aligned with TeamCity behavior).
The approach that we have currently implemented processes every build in a build chain (similarly to how other providers send us webhook first when a job finishes and then when a pipeline finishes). Based on the discussion, there might be issues in which the same build will be running for 2 different build chains, as we might end up with different composite builds for the same build (one for each chain).
A different approach (that they suggested and its implemented with this PR) would be to only process the final composite build of a chain (ignoring all the builds before) and retrieve all its dependencies (previous builds for the chain) when processing it (and sending all the webhooks together). This will avoid the race conditions and it will make the implementation easier (we only need to traverse the chain graph once from right to left, which is aligned with TeamCity behavior).