[Bug]: expression evaluator returns None for multi-expression templates without surrounding text

[markuswondrak]

Bug Description

In the workflow expression evaluator (src/specify_cli/workflows/expressions.py), evaluate_expression() returns None when a template contains two or more {{ }} blocks with no surrounding literal text (e.g., "{{ context.run_id }} {{ inputs.issue }}").

Root cause: The regex _EXPR_PATTERN = re.compile(r"\{\{(.+?)\}\}") uses non-greedy (.+?), but fullmatch() defeats non-greediness. For "{{ a }} {{ b }}", fullmatch succeeds by expanding (.+?) to capture everything between the first {{ and the last }}, producing "a }} {{ b" as the expression body. This garbage is passed to _evaluate_simple_expression() → dot-path lookup fails → returns None. Since fullmatch succeeded, the function returns None directly (line 389), bypassing the safe sub() multi-expression path that would have correctly interpolated each expression separately.

Impact: Any workflow step using a multi-expression template without surrounding text silently resolves to None. In our case, a finish step with args: "{{ context.run_id }} {{ inputs.issue }}" resolved to None, causing the finish command to receive the string "None" and fail with "no issue was provided" despite issue: "23" being in the run inputs.

Steps to Reproduce

1. Create a workflow with a command step using a two-expression template:

   - id: finish
     command: my.command
     input:
       args: "{{ context.run_id }} {{ inputs.issue }}"

2. Run the workflow with issue: "23" in inputs.

3. Observe that state.json shows step_results.finish.input.args: null instead of "47c5eb4b 23".

Direct reproduction:

import sys
sys.path.insert(0, "/path/to/specify-cli/lib/python3.12/site-packages")

from specify_cli.workflows.expressions import evaluate_expression
from specify_cli.workflows.base import StepContext

ctx = StepContext(
    inputs={"issue": "23"},
    run_id="47c5eb4b",
)

template = "{{ context.run_id }} {{ inputs.issue }}"
result = evaluate_expression(template, ctx)

print(f"Template: {template!r}")
print(f"Result:   {result!r}")
print(f"Type:     {type(result).__name__}")

Output:

Template: '{{ context.run_id }} {{ inputs.issue }}'
Result:   None
Type:     NoneType

Expected Behavior

evaluate_expression("{{ context.run_id }} {{ inputs.issue }}", ctx) should return "47c5eb4b 23" (a string with both values interpolated).

The sub() multi-expression path (lines 392-396) is correct and would produce the right result. The bug is that fullmatch incorrectly succeeds for two-expression templates, bypassing the safe path.

Actual Behavior

evaluate_expression returns None. The captured group from fullmatch is "context.run_id }} {{ inputs.issue" (garbage), which fails dot-path resolution and returns None. This None is then converted to the string "None" by CommandStep.execute() (line 57: args_str = str(resolved_input.get("args", ""))), causing downstream commands to receive the confusing string "None" instead of an empty string or error.

Specify CLI Version

0.11.9

AI Agent

opencode

Operating System

Ubuntu 22.04 (Linux x86_64)

Python Version

Python 3.12.3

Error Logs

$ python3 reproduce.py
Template: '{{ context.run_id }} {{ inputs.issue }}'
Result:   None
Type:     NoneType

BUG CONFIRMED: evaluate_expression returned None
Expected: '47c5eb4b 23' (string)

Additional Context

Why single-expression and shell-step templates work:

Template type	Example	fullmatch result	Why it works
Single expression	{{ inputs.issue }}	Succeeds, captures inputs.issue	Correctly treated as single expression
Shell step (text prefix)	bash script.sh "{{ inputs.issue }}"	Fails (starts with bash)	Falls to sub() path — correct
Two expressions, no prefix	{{ context.run_id }} {{ inputs.issue }}	Succeeds incorrectly — captures garbage	BUG — returns None

Proposed fix:

Add a count("{{") == 1 guard before fullmatch in expressions.py lines 386-389:

    # Single expression: return typed value.
    # Guard against multi-expression templates: fullmatch with non-greedy
    # (.+?) treats "{{ a }} {{ b }}" as a single expression, capturing
    # "a }} {{ b" as the body. Only use the single-expression fast path
    # when there is exactly one {{ ... }} block, so two-expression
    # templates fall through to the sub() interpolation path.
    stripped = template.strip()
    if stripped.count("{{") == 1:
        match = _EXPR_PATTERN.fullmatch(stripped)
        if match:
            return _evaluate_simple_expression(match.group(1).strip(), namespace)

Verification after fix:

>>> evaluate_expression("{{ context.run_id }} {{ inputs.issue }}", ctx)
'47c5eb4b 23'   # FIXED

This is a one-line behavioral guard that preserves typed return for single-expression templates while correctly routing multi-expression templates to the sub() path.

Related issue: #3073 (expression evaluator silently ignores unknown filters) — similar "silent failure" pattern in the expression engine, but different root cause.

Workaround: Change the workflow template to use a single expression (args: "{{ context.run_id }}") and have the command read issue from .specify/workflows/runs/<run_id>/inputs.json directly.

AI disclosure: This issue was investigated and written with AI assistance (opencode); I reproduced and verified the behavior against specify-cli 0.11.9 myself.

[github-actions]

Bug assessment — multi-expr-returns-none: Valid · severity high

---

Bug Assessment: Expression Evaluator Returns None for Multi-Expression Templates

• Slug: multi-expr-returns-none
• Created: 2026-06-29T14:04:55Z
• Source: issue [Bug]: expression evaluator returns None for multi-expression templates without surrounding text #3208
• Verdict: valid
• Severity: high

Report (summarized)

Reported by @markuswondrak (AI-assisted, self-verified against specify-cli 0.11.9 on Ubuntu 22.04 / Python 3.12.3). The evaluate_expression() function returns None for any template containing two or more {{ }} blocks with no surrounding literal text — e.g., "{{ context.run_id }} {{ inputs.issue }}". The reporter correctly traced the root cause to a regex fullmatch that unexpectedly succeeds for such templates, producing a garbage capture group that fails dot-path resolution silently. A concrete workflow reproduction and a proposed one-line fix are included.

Symptom

evaluate_expression("{{ context.run_id }} {{ inputs.issue }}", ctx) returns None instead of the expected interpolated string (e.g., "47c5eb4b 23"). Downstream, CommandStep.execute() converts the None to the literal string "None" (line 57: args_str = str(resolved_input.get("args", ""))), causing commands to receive nonsensical input with no error.

Reproduction

1. Construct a StepContext with inputs={"issue": "23"} and run_id="47c5eb4b".
2. Call evaluate_expression("{{ context.run_id }} {{ inputs.issue }}", ctx).
3. Observe return value is None (type NoneType), not "47c5eb4b 23".
4. In a workflow: use args: "{{ context.run_id }} {{ inputs.issue }}" in a command step, run with issue: "23". The step receives args_str = "None".

Suspected Code Paths

• src/specify_cli/workflows/expressions.py:94 — _EXPR_PATTERN = re.compile(r"\{\{(.+?)\}\}"): The non-greedy (.+?) with fullmatch() is the origin of the defect.
• src/specify_cli/workflows/expressions.py:387 — match = _EXPR_PATTERN.fullmatch(template.strip()): For "{{ context.run_id }} {{ inputs.issue }}", fullmatch forces the non-greedy group to expand all the way to the last }}, capturing " context.run_id }} {{ inputs.issue " as the expression body.
• src/specify_cli/workflows/expressions.py:388-389 — if match: return _evaluate_simple_expression(match.group(1).strip(), namespace): Garbage expression passed to dot-path resolver → returns None. Function returns early, never reaching the sub() path.
• src/specify_cli/workflows/expressions.py:391-396 — _EXPR_PATTERN.sub(_replacer, template): The correct multi-expression path that would have produced "47c5eb4b 23" — bypassed because fullmatch already returned.
• src/specify_cli/workflows/steps/command/__init__.py:57 — args_str = str(resolved_input.get("args", "")): Converts None to the string "None", masking the failure.

Root Cause Hypothesis

Confidence: high. The code was written under the assumption that _EXPR_PATTERN.fullmatch() succeeds only when the template is a single {{ expr }} and nothing else. This is correct for single-expression templates, but fullmatch with non-greedy (.+?) also succeeds for templates of the form "{{ a }} {{ b }}": Python's regex engine expands (.+?) greedily enough to consume " a }} {{ b " so the terminal \}\} anchors to the last }} in the string. The code therefore enters the single-expression fast path with junk input, calls _evaluate_simple_expression("context.run_id }} {{ inputs.issue", namespace), which silently returns None from _resolve_dot_path() after failing dot-path traversal. No exception is raised, and the caller receives None with no indication of the problem.

Proposed Remediation

Preferred: Add a count("{{") == 1 guard immediately before the fullmatch call in evaluate_expression(). This restricts the single-expression fast path to templates that genuinely contain only one {{ }} block, ensuring all multi-expression templates fall through to the correct sub() interpolation path. The change is minimal and preserves the typed return value for the single-expression case:

# In evaluate_expression(), replace lines 386-389:

# Single expression: return typed value.
# Guard against multi-expression templates: fullmatch with (.+?) incorrectly
# succeeds for "{{ a }} {{ b }}" by expanding the capture to "a }} {{ b".
# Only use the single-expression fast path when exactly one {{ block is present.
stripped = template.strip()
if stripped.count("{{") == 1:
    match = _EXPR_PATTERN.fullmatch(stripped)
    if match:
        return _evaluate_simple_expression(match.group(1).strip(), namespace)

Alternatives:

• Use a stricter dedicated pattern for the fullmatch check only — e.g., re.compile(r"\{\{((?:(?!\}\}).)+?)\}\}") — which uses a negative lookahead to prevent }} inside the capture group. This is more robust against pathological inputs but adds complexity and a second compiled pattern. Trade-off: handles edge cases that the count guard does not (e.g., a {{ inside a string literal inside an expression), at the cost of readability.
• Change fullmatch to re.fullmatch(r"\{\{([^}]|(?!}})})*\}\}", stripped) inline without modifying _EXPR_PATTERN, leaving the sub() pattern unchanged. Equivalent robustness to the above, slightly less readable.

Files likely to change:

• src/specify_cli/workflows/expressions.py (the guard, ~3 lines)
• tests/test_workflows.py (add regression test for the multi-expression-no-text case)

Tests to add or update:

• TestExpressions.test_multi_expression_no_surrounding_text: assert evaluate_expression("{{ context.run_id }} {{ inputs.issue }}", ctx) == "47c5eb4b 23" — directly exercises the fixed code path.
• Variant: two expressions adjacent without even a space: "{{ a }}{{ b }}" — verify both resolve correctly.
• Verify that single-expression templates still return typed values (not strings), confirming the fast path still works.
• Verify that CommandStep.execute() with the same template receives a proper string (not "None") at args_str.

Risks & Considerations

• No API breakage: The change only affects templates with two or more {{ }} blocks and no surrounding literal text. Single-expression templates continue to use the fast path and return typed values. Mixed templates (text + expression) have always used the sub() path and are unaffected.
• Existing behavior: Any caller that was (inadvertently) receiving None and handling it gracefully will now receive a string. This is the correct and intended behavior, not a regression.
• _replacer returns "" for None: Note that in the sub() path, a None value is already converted to an empty string (line 394: return str(val) if val is not None else ""). This means a template like "{{ missing }} {{ inputs.issue }}" (where missing does not resolve) will return " 23" (empty string for the missing part) rather than "None 23" — this is consistent with the existing behavior for mixed templates and is the right semantic.
• Related issue [Bug]: workflow expression evaluator silently ignores unknown filters #3073: The pattern of silent failures in the expression engine has surfaced before. A broader audit of _evaluate_simple_expression() return-None-on-failure behavior may be warranted to ensure callers always distinguish "resolved to null" from "resolution failed".

Open Questions

• [NEEDS CLARIFICATION: Are there workflow YAML templates in the wild (in production or internal repos) using the two-expression-no-text pattern that are currently silently broken? If so, a migration note or changelog entry is warranted.]
• [NEEDS CLARIFICATION: Should _evaluate_simple_expression() distinguish "path resolved to null" from "path not found" to enable better error reporting in the future?]

---

Posted on behalf of @mnriem by GitHub Copilot (model: claude-sonnet-4.6, autonomous).

Generated by 🐛 Assess Bug from Labeled Issue for issue #3208 · 155.7 AIC · ⌖ 13.7 AIC · ⊞ 31.7K · ◷