fix(workflow-executor): carry the collection name on step error logs

[Scra3]

Companion to ForestAdmin/forestadmin-server#8415 (PRD-842).

Why

A client's step error logs are the only place the server's technical message surfaces. The operator deliberately sees a generic "This step couldn't be completed…", so when a step fails for a schema reason, the client's own tech diagnoses it from these logs — base-step-executor logs error.message plus cause and stack at Error level for every WorkflowExecutorError, which includes every WorkflowPortError.

Those logs carried runId, stepId, stepIndex and stepType — but not the collection, even though the Debug and Info logs did. On exactly the failure this came from ("collection X has no usable primary key") the collection is the one field you want to filter on.

What changed

collection moves into logCtx rather than being added to each catch branch. That way it reaches all three error sites at once — timeout, WorkflowExecutorError, unexpected — and any log site added later gets it for free, which is how it came to be missing in the first place.

The two Debug/Info call sites that spread it manually are simplified accordingly, so there is one source of truth.

baseRecordRef is non-optional on ExecutionContext (execution-context.ts:29), so the getter cannot throw while logging an error — worth stating since it now runs on the error path.

Verification

• tsc --noEmit clean.
• Full suite: 1469 passed. Two SQLite store suites timed out in beforeEach on the full run (259s, loaded machine) and pass in isolation in 17s — unrelated to a log-context getter.

🤖 Generated with Claude Code

Note

Fix BaseStepExecutor to include collection name in step error logs

Moves the collection field into the logCtx getter in base-step-executor.ts so it is available to all log calls, including error logs. Previously, collection was only added manually to the 'Step execution started' log and was absent from other log invocations.

^{Macroscope summarized 0ec9d2d.}

[linear-code]

PRD-842

[qltysh]

1 new issue

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

[qltysh]

Coverage Impact

This PR will not change total coverage.

Modified Files with Diff Coverage (1)

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