[christophebrun-forest]

Part of PRD-2028 (first of two PRs). No behaviour change.

Why

A deterministic Decision condition can only read a Get Data step today: the source resolution filters on ReadRecord steps. PRD-2028 adds a Sub-workflow's End as a source, and PRD-995 / PRD-996 will add more kinds. This PR makes the resolution take a source kind first, so each kind brings its own resolver.

What

• DeterministicConditionSchema accepts an optional sourceType, limited to 'get-data' for now. Absent or null parses to 'get-data', which is all an older orchestrator sends, so the parsed type is never optional.
• ConditionStepExecutor.resolveConditionValue is an exhaustive switch on sourceType: adding a kind to the enum fails to compile until its case exists. The Get Data code moves unchanged into resolveGetDataValue.
• The "could not be resolved" warning now logs the sourceType, since the reason depends on which resolver ran.

Contract and rollout

• The orchestrator (PRD-2029) will send sourceType: 'sub-workflow' for an End source. That value and its resolver come in the next PR.
• An executor from this PR on rejects a sourceType it does not know (InvalidStepDefinitionError). An executor predating this PR does not: zod strips the unknown key, so it would read a Sub-workflow End condition as a Get Data one, find the source not reached, and route to the fallback. The executor-version floor in PRD-2029 is what keeps a new source kind off those executors.

Tests

Existing executor tests pass unchanged in substance; their deterministic steps now go through ConditionStepDefinitionSchema, like a real step does. Added:

• the schema reads an absent or null sourceType as 'get-data', keeps an explicit one, and rejects an unknown kind;
• the step-definition mapper turns an unknown kind into an InvalidStepDefinitionError;
• an explicit 'get-data' resolves like an absent one.

🤖 Generated with Claude Code

Note

Resolve deterministic conditions by sourceType in workflow executor

• Adds a sourceType field to deterministic conditions, validated against CONDITION_SOURCE_TYPES (only get-data) in step-definition.ts. Missing or null values default to get-data.
• ConditionStepExecutor.resolveConditionValue now dispatches on sourceType in condition-step-executor.ts; the existing lookup is renamed to resolveGetDataValue.
• Also adds sourceType to the server condition type in server-types.ts and updates docs and tests.
• Behavioral Change: an unrecognized sourceType now throws InvalidStepDefinitionError, and schema parsing normalizes absent/null sourceType to get-data, which shows up in parsed-condition assertions.

^{Macroscope summarized 62740af.}

[linear-code]

PRD-2028

[qltysh]

1 new issue

Tool	Category	Rule	Count
qlty	Structure	Function with many returns (count = 4): resolveGetDataValue	1

[qltysh]

Coverage Impact

Unable to calculate total coverage change because base branch coverage was not found.

Modified Files with Diff Coverage (2)

Rating	File	% Diff	Uncovered Line #s
	...ges/workflow-executor/src/executors/condition-step-executor.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.