Understanding Stack Dependency Behavior with Skipped vs Failed Runs

When working with stack dependencies in Spacelift, it's important to understand how the system handles different run states and when dependency chains are broken.

How Dependency Chains Work

Stack dependency chains behave differently depending on whether upstream runs fail or are skipped:

• Failed runs: When a run fails in a dependency chain, the chain "breaks" and all subsequent runs will be cancelled

• Skipped runs: When a run is skipped (not failed), the chain is not broken, so downstream stacks will still proceed once all parents have finished

Example Scenario

Consider this dependency structure: A → B → C

If stack A fails:

• Stack B will be skipped (not failed)

• Stack C will still run because B was skipped, not failed

For a more complex example with multiple dependencies:

• If stack B fails causing stack C to skip

• Stack F (dependent on both C and E) will still run if E passes and C is skipped

• This is because none of F's direct parents failed - one succeeded (E) and one was skipped (C)

Alternative Solution: Trigger Policies

If you need all downstream stacks to stop when any upstream stack fails, consider using Trigger policies instead of stack dependencies. You can configure a trigger policy to emit triggers only if all parents succeeded.

This approach is particularly useful for the "diamond problem" pattern where you want strict control over when downstream stacks execute. See the trigger policy documentation for implementation details.

Key Takeaway

By design, downstream runs that never execute are marked as "Skipped" or "Cancelled", not "Failed". The "Failed" status is reserved for runs that actually start and encounter an error during execution. This distinction is crucial for understanding how dependency chains behave in your workflows.