feat(workflow-executor): evaluate the operators a list view filter offers, relative dates included

[Scra3]

fixes PRD-1147, fixes PRD-1130

Why

A deterministic Decision on a Date field could only say is, is not, is present, is blank. Forest exposes before/after and a relative family for dates, none of which were in the contract, so the first condition anyone writes on a date could not be written. Meanwhile the contract carried three operators (>=, <=, not_in) that the editor can never build, since the front registry does not define them.

What

Operator set = what a list view filter offers. CONDITION_OPERATORS goes from 12 to 23: the three orphans leave, fourteen arrive.

Family	Operators
Absolute dates	before, after
Relative dates	past, future, today, yesterday, previous_x_days, previous_x_days_to_date, before_x_hours_ago, after_x_hours_ago
Strings	starts_with, ends_with, i_contains
Arrays	includes_all

Relative dates read an injected Clock, { now, timezone }, never the machine's. The evaluator stays pure. The step executor builds one clock per step so every row of a Decision sees the same instant.

Timezone is the project's, carried on the run. AvailableStepExecution.timezone is new; the mapper falls back to UTC when the project has none or the orchestrator predates the field. The machine's zone is never used: the fleet runs several executor instances and the same run must route the same on each.

Semantics mirror datasource-toolkit's time transforms, which is what the list filter runs on: day windows exclude their end and, like the toolkit's GreaterThan / GreaterThanOrEqual split, include their start for a calendar date only, previous_x_days excludes today, previous_x_days_to_date includes it up to the instant. A calendar date (Dateonly) is read at midnight in the project zone, otherwise a Honolulu record's own today is counted as yesterday. i_contains folds case and keeps accents, measured on Postgres: 'É' ILIKE '%é%' holds, 'é' ILIKE '%e%' does not.

The trace records evaluatedAt and timezone. A relative condition makes routing depend on the clock; without the instant, a check on "previous 7 days" cannot be explained a day later.

Decisions taken with product (on PRD-1147)

• Dates are evaluated at the instant the condition is evaluated.
• Timezone: project's, fallback UTC. Not the user's (automated runs have none), not the host's.
• A retry may route differently. Accepted.
• All operators ship together.

Compatibility

Dropping greater_than_or_equal, less_than_or_equal and not_in makes a published workflow that still carries one of them fail at parse on this executor (and be refused by the orchestrator's parser). The editor never offered them, and the deterministic Decision has only been open on executor 1.27.0 since 2 September, so no such workflow should exist; a hand-edited BPMN is the only way to have one. The orchestrator and the front move their gate back to the sentinel until this ships, since 1.27.0 refuses the fourteen new operators.

Paired with

• forestadmin-server: the contract list, the value rules per operator, and sending project.timezone on the run.
• forestadmin: the editor's allowed list and the run view.

Until the orchestrator sends the timezone, relative dates resolve in UTC.

Tests

1724 passing. Every new operator is pinned with a fixed clock in Europe/Paris, the calendar-date case in Pacific/Honolulu, and the condition executor proves the context timezone reaches the evaluator with fake timers straddling midnight.

Note

Add list-view filter operators with timezone-aware relative date evaluation to deterministic-condition-evaluator

• Expands the deterministic condition operator set to match list-view filters: adds includes_all, starts_with, ends_with, i_contains, before, after, past, future, today, yesterday, previous_x_days, previous_x_days_to_date, before_x_hours_ago, and after_x_hours_ago; removes greater_than_or_equal, less_than_or_equal, and not_in from step-definition.ts
• Introduces a Clock carrying the current instant and project timezone; ConditionStepExecutor.evaluateDeterministically captures one clock per step and passes it through every condition evaluation in condition-step-executor.ts
• Date-only values are interpreted as midnight in the project timezone; SQL-style datetime strings (space separator, bare-hour offset) are now parseable via deterministic-condition-evaluator.ts
• ExecutionContext and AvailableStepExecutionSchema now require a non-empty timezone string; run-to-available-step-mapper forwards valid IANA zones and defaults to UTC when absent or invalid
• Persists evaluatedAt and timezone in DeterministicConditionExecutionParams alongside existing evaluation results
• Behavioral Change: EVALUATORS no longer provides greater_than_or_equal, less_than_or_equal, or not_in; existing conditions using these operators will fail validation against DeterministicConditionSchema. All non-presence evaluations now require an injected Clock, so direct callers of evaluateOperator must supply one.

^{Macroscope summarized 66fbb91.}

[linear-code]

PRD-1147

PRD-1130

[qltysh]

4 new issues

Tool	Category	Rule	Count
qlty	Structure	Function with many returns (count = 4): evaluateDeterministically	2
qlty	Structure	High total complexity (count = 66)	1
qlty	Structure	Function with many parameters (count = 4): evaluateOperator	1

[macroscopeapp]

🟠 High validated/execution.ts:53

Invalid timezone values such as "Fantasia/Castle" pass AvailableStepExecutionSchema.parse, causing Luxon to evaluate relative-date windows with an invalid clock zone and silently route Decisions to their fallback. Validate the value as an IANA zone here, or normalize invalid values to UTC before they reach the evaluator.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @packages/workflow-executor/src/types/validated/execution.ts around line 53:

Invalid timezone values such as `"Fantasia/Castle"` pass `AvailableStepExecutionSchema.parse`, causing Luxon to evaluate relative-date windows with an invalid clock zone and silently route Decisions to their fallback. Validate the value as an IANA zone here, or normalize invalid values to `UTC` before they reach the evaluator.

[qltysh]

Coverage Impact

This PR will not change total coverage.

Modified Files with Diff Coverage (4)

Rating	File	% Diff	Uncovered Line #s
	...ow-executor/src/executors/deterministic-condition-evaluator.ts	100.0%
	...ges/workflow-executor/src/executors/condition-step-executor.ts	100.0%
	...workflow-executor/src/adapters/run-to-available-step-mapper.ts	100.0%
	packages/workflow-executor/src/types/validated/step-definition.ts	100.0%
	Total	100.0%

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.