Bug Description
In the workflow expression evaluator, an unknown pipe filter is silently ignored — the value passes through unfiltered and the run completes with no error. Only five filters are registered (default, join, map, contains, from_json); any other filter name (a typo, or an unsupported one a user reasonably reaches for, e.g. length) is dropped silently, so the author gets a wrong value with no signal that the filter did nothing.
Root cause: src/specify_cli/workflows/expressions.py — the filter dispatch falls through to return value when no recognized filter matches (both the no-arg form and the unrecognized name(arg) form). This is the same "unknown-filter path" that the strict from_json handling already guards against for its own forms; it is unguarded in general.
Steps to Reproduce
- Use an unregistered filter in a workflow expression, e.g. a shell step:
- id: s
type: shell
run: "echo count={{ [1, 2, 3] | length }}"
specify workflow run <workflow>
- The step prints
count=[1, 2, 3] and the run completes — the length filter was silently ignored. (evaluate_expression("{{ [1,2,3] | length }}", ctx) returns [1, 2, 3], not an error or a count.)
Expected Behavior
An unregistered filter should fail loudly — a clear error naming the offending filter (and the valid ones) — so a typo or unsupported filter surfaces immediately instead of corrupting downstream expressions/conditions/gates silently. This matches the project's existing stance: from_json already raises on its mis-wired forms specifically to avoid "silently falling through to the unknown-filter path and returning the unparsed value," and fan-out items: was made fail-loud in #2957 for the same reason.
Actual Behavior
The unknown filter is silently dropped (return value); the expression yields the unfiltered value and the run reports success. No error, no warning.
Specify CLI Version
0.11.3
AI Agent
Claude Code
Operating System
macOS 14.5
Python Version
Python 3.11.15
Error Logs
(none — that is the bug: no error is raised; the filter is silently ignored)
Additional Context
Found while exercising workflow expressions end-to-end. Happy to send a small PR that makes the unknown-filter path raise (reusing the existing ValueError style from from_json), preserving all five registered filters.
AI disclosure: this issue was investigated and written with AI assistance (Claude Code); I reproduced and verified the behavior against the current tree myself.
Bug Description
In the workflow expression evaluator, an unknown pipe filter is silently ignored — the value passes through unfiltered and the run completes with no error. Only five filters are registered (
default,join,map,contains,from_json); any other filter name (a typo, or an unsupported one a user reasonably reaches for, e.g.length) is dropped silently, so the author gets a wrong value with no signal that the filter did nothing.Root cause:
src/specify_cli/workflows/expressions.py— the filter dispatch falls through toreturn valuewhen no recognized filter matches (both the no-arg form and the unrecognizedname(arg)form). This is the same "unknown-filter path" that the strictfrom_jsonhandling already guards against for its own forms; it is unguarded in general.Steps to Reproduce
specify workflow run <workflow>count=[1, 2, 3]and the run completes — thelengthfilter was silently ignored. (evaluate_expression("{{ [1,2,3] | length }}", ctx)returns[1, 2, 3], not an error or a count.)Expected Behavior
An unregistered filter should fail loudly — a clear error naming the offending filter (and the valid ones) — so a typo or unsupported filter surfaces immediately instead of corrupting downstream expressions/conditions/gates silently. This matches the project's existing stance:
from_jsonalready raises on its mis-wired forms specifically to avoid "silently falling through to the unknown-filter path and returning the unparsed value," andfan-outitems:was made fail-loud in #2957 for the same reason.Actual Behavior
The unknown filter is silently dropped (
return value); the expression yields the unfiltered value and the run reports success. No error, no warning.Specify CLI Version
0.11.3
AI Agent
Claude Code
Operating System
macOS 14.5
Python Version
Python 3.11.15
Error Logs
Additional Context
Found while exercising workflow expressions end-to-end. Happy to send a small PR that makes the unknown-filter path raise (reusing the existing
ValueErrorstyle fromfrom_json), preserving all five registered filters.AI disclosure: this issue was investigated and written with AI assistance (Claude Code); I reproduced and verified the behavior against the current tree myself.