We have a reasonably complex build pipeline that uses snapshot dependencies. In particular there are several downstream leaf builds (one for each maintenance branch of our product) that depend on (amongst other things) a single upstream root build (for a testing tool used across all product branches).
When we commit a change to our testing tool it triggers literally dozens of builds. This is caused by the VCS triggers in the leaf builds each triggering their own duplicate set of builds in the testing tool's pipeline (the numbers are greater in both dimensions that shown in the diagram).
The dependencies and triggers are configured so that the duplicates get weeded out when the builds come to run -- we are not *running* more builds than we should.
However the pending testing tool builds (most of which never run) are far greater in number than anything else. This means that it is impossible to keep an eye on the size of the build queue and use this as an indicator that the build system is healthy. It also makes it difficult to judge when a build near the bottom of the queue is going to be run.
The snapshot dependency functionality is great, but the flooding of the build queue is a serious usability problem.