Debugging Silent Pipeline Failures: When your if Statement Evaluates to Null

It’s the ultimate “it works on my machine” moment for DevOps engineers. You’ve defined a variable, you can see it in the logs, and yet your ${{ if eq(variables.isProduction, 'true') }} block is completely ignored. The stage isn’t skipped; it’s simply gone, as if the code never existed. You aren’t crazy—you’ve just fallen into the “Expression Gap.”

A “Silent Failure” occurs when an Azure DevOps expression evaluates to null or false because it’s being asked to look at data that hasn’t been generated yet. The most common culprit is trying to use a runtime variable—like a task output or a variable from a Library group—inside a compile-time ${{ }} block. Because ${{ }} is evaluated during the pipeline expansion phase (before any tasks run), it sees these future variables as empty. This guide teaches you how to identify, debug, and refactor these silent failures, moving your logic from fragile compile-time guesses to reliable runtime conditions.

1. The Timing Mismatch: Compile-Time vs. Runtime

The primary cause of silent failure is a fundamental misunderstanding of the “Boundary of Visibility.” Azure DevOps pipelines have two distinct “minds”: the expansion engine and the execution engine.

The Expression Gap (Timing Mismatch)

1.1: What ${{ }} Really Sees

Compile-time expressions are resolved when the YAML is fetched and templates are unrolled. At this moment, the engine only has access to a very narrow slice of data:

• YAML Parameters: Explicitly passed into the template.
• Static Variables: Hardcoded in the variables: block of the YAML files.
• System Variables (Pre-run): Values known before the first task starts, such as Build.Reason, Build.SourceBranch, or System.TeamProject.

Everything else—Variables set in the Azure DevOps UI, secret variables, values from Variable Groups, and any data produced by a script—is invisible to ${{ }}.

1.2: The “Null” Result Trap

When an expression tries to access a non-existent variable, it evaluates to null. In the logic engine, null is functionally identical to false. If you wrap a job in an ${{ if }} block that resolves to null, the orchestrator deletes that job from the final plan. Because the code is removed before it even reaches the agent, you won’t see a “skipped” icon in the UI; the code simply vanishes, leaving no trace in the standard execution logs.

2. Three Common Patterns of Silent Failure

2.1: The “Environment Toggle” Failure

Engineers often try to use ${{ if eq(variables.envName, 'Prod') }} where envName is defined in a Variable Group linked in the Library. Because Variable Groups are injected after the YAML expansion phase, the ${{ if }} block always sees null. The specialized security or production steps you intended to run are silently dropped every single time.

2.2: The “Output Variable” Misconception

Another frequent mistake is attempting to use ${{ if eq(dependencies.A.outputs['task.myVar'], 'true') }}. At compile-time, the dependencies object is entirely empty because Job A hasn’t even been assigned to an agent yet. The expression resolves to null, and the dependent step is removed from the plan.

2.3: The “Template Parameter” vs “Variable” Blur

Passing a runtime variable into a template parameter that is then used in an ${{ if }} statement is a guaranteed failure.

# Main Pipeline
- template: my-template.yml
  parameters:
    isProd: $(isProdVariable) # Literal string passed

# Template
- ${{ if eq(parameters.isProd, 'true') }}:
  - script: echo "Running in Prod"

The template receives the literal string $(isProdVariable), not its value. Since the string $(isProdVariable) is not equal to true, the code block is deleted.

3. The Debugger’s Toolkit: Expanded YAML

To fix what you can’t see, you must change how you view your code.

3.1: The “View YAML” Button

The most important tool in your arsenal is the Expanded YAML view.

• Pre-run: In the Pipeline Editor, click the vertical ellipsis and select “Download full YAML”.
• Post-run: In the run summary, go to “Download logs” and look for azure-pipelines-expanded.yaml.

This view shows the pipeline after all ${{ }} and templates have been resolved. If your code is missing from this file, the error is at compile-time (${{ }}). If it is present but skipped in the UI, the error is at runtime ($[ ]).

3.2: The Echo-Debug Pattern

When building complex templates, always include a debug step that converts your parameters to JSON. This reveals type coercion issues (like booleans turning into strings) and missing values.

- script: echo '${{ convertToJson(parameters) }}'
  displayName: '🔍 Debug: Parameter Expansion'
  condition: eq(variables['System.Debug'], 'true')

4. Refactoring for Success: Moving to Runtime Conditions

4.1: When to Use condition:

If you need to check a value that might change during execution, you must move the logic from ${{ if }} to the condition: property of a job or step. Use the runtime syntax $[ ] to ensure evaluation happens after variables are resolved.

Wrong (Compile-time):

- ${{ if eq(variables.isProd, 'true') }}:
  - script: ./deploy.sh

Right (Runtime):

- script: ./deploy.sh
  condition: eq(variables['isProd'], 'true')

4.2: Mapping Variables Properly

For cross-job dependencies, use the variables: block to map the runtime output into a local scope. This makes your conditions cleaner and easier to read.

- job: B
  dependsOn: A
  variables:
    readyFlag: $[ dependencies.A.outputs['Check.isReady'] ]
  steps:
  - script: ./run.sh
    condition: eq(variables.readyFlag, 'true')

5. Best Practices to Avoid the Gap

1. Parameters for Structure: If a value determines what steps are in the pipeline (e.g., Windows vs Linux), use a parameter.
2. Variables for Values: If a value determines if a step runs (e.g., Branch name or Approval), use a variable and a condition:.
3. The “Fail-Fast” Strategy: Use runtime parameters with restricted values to prevent invalid states from ever reaching the engine.
4. Never Check UI Variables in ${{ }}: Treat any variable not hardcoded in the current YAML file as “invisible” to the ${{ }} syntax.

Hands-On Example: The “Vanish” Bug

Consider a deployment step that only runs for the main branch. A developer writes: ${{ if eq(variables['Build.SourceBranch'], 'refs/heads/main') }}. The pipeline runs for a PR, but the deployment step is missing from the logs entirely.

The “Vanish Bug” Diagnostic Flow

The Fix: Map the branch name to a runtime variable and use a condition:.

variables:
  isMain: $[ eq(variables['Build.SourceBranch'], 'refs/heads/main') ]

steps:
- script: ./deploy.sh
  condition: eq(variables.isMain, 'true')

Now, in the PR run, the step will appear in the UI with a “Skipped” icon, providing a clear audit trail that the logic was evaluated correctly.

Key Takeaways

1. Parameters are for Structure; Variables are for Values.
2. Missing from Expanded YAML = Compile-time failure.
3. ${{ if }} blocks vanish; conditions merely skip.
4. Always verify with convertToJson during development.

Sources

• Microsoft Learn: Expression evaluation timing
• Microsoft Learn: Expanded YAML view
• Official Azure DevOps Blog: Debugging YAML Templates