TeamCity Cloud creates a history build for one build configuration during nightly builds

Problem

A build configuration runs on an older VCS revision than a build of the same configuration that already finished, so TeamCity marks it a History build (it shows History in the Changes column). Downstream steps or tests then run against the older artifact and can fail when they expect newer code. The behavior appears in automated build chains, such as a scheduled nightly run, where the configuration is part of snapshot dependencies and is reachable through several triggers. No new commits are required for it to occur.

Cause

TeamCity fixes one source revision for an entire build chain at the moment the chain is queued, and every build in that chain uses it. This is revision synchronization. A configuration can be reachable through more than one chain: it may have several Finish Build Triggers, or be a snapshot dependency of more than one downstream configuration. In that case it is built more than once during the same run. Those chains do not always fix the same revision. A chain can reuse an earlier suitable build that was pinned to an older revision, or be assembled from dependencies fixed at an older point. When a build runs later on an older revision than a build that already ran, TeamCity marks it a History build.

See How snapshot dependencies work for how the chain revision is fixed at queue time and when a finished build is reused.

Resolution

Run the chain so that each configuration is built once per run, on one revision:

1. Trigger only the top of the chain. Put the schedule or VCS trigger on the single final configuration that depends, directly or transitively, on the rest. Remove the Finish Build Triggers from the intermediate configurations. Triggering the top build then queues the whole chain and builds each configuration once, in order, on one revision.
2. Keep the dependency graph pointing one direction only. No configuration may trigger or depend on a configuration that, directly or through others, triggers it back. A build chain cannot contain a cycle.
3. Keep Enforce revisions synchronization enabled and consistent across the snapshot dependencies in the chain, so every part uses the same revision. Enabling it on some dependencies and disabling it on others lets different parts resolve to different revisions.
4. To always build the latest revision instead of reusing an earlier build, disable Do not run a new build if there is a suitable one on the relevant snapshot dependencies.

VCS triggers on intermediate configurations do not cause this on their own, because they fire only when there are new commits. The overlapping chains come from the Finish Build Triggers.