fix(workflow-executor): scope collection schema cache by rendering [PRD-440]

[christophebrun-forest]

Problem

When workflows run on the same collection across different renderings, a run could operate with the collection schema (field display names and which fields are exposed, plus actions) belonging to a different rendering. Because workflow steps reference fields by their display name, this led to fields being mismatched or resolved incorrectly during a run.

Root cause

SchemaCache is a process-wide singleton keyed only by collectionName. The schema is fetched per run via getCollectionSchema(collectionName, runId) (the orchestrator resolves the rendering from the runId), so the fetched schema is rendering-specific — but the cache key dropped the rendering. Within the cache TTL (default 10 min):

Run A (rendering 100) → resolve("customers") → fetch schema(100) → cache["customers"] = schemaA
Run B (rendering 200) → resolve("customers") → cache HIT → returns schemaA  ❌

Fix

Key cache entries by (renderingId, collectionName):

• SchemaCache — composite key; get/set(renderingId, …); the global iterator is replaced by entriesForRendering(renderingId) (NUL separator so rendering 1 is never confused with 11).
• SchemaResolver — binds the run's renderingId and uses it for cache get/set.
• StepExecutorFactory — passes step.user.renderingId to the resolver.
• AgentClientAgentPort — builds action endpoints from the current user's rendering via entriesForRendering(user.renderingId) (iterating the whole cache would otherwise mix action schemas across renderings).

renderingId (not runId) is the cache dimension on purpose: two runs of the same rendering keep sharing the cache (efficiency), only different renderings are isolated. TTL/eviction logic is unchanged, just applied per (rendering, collection). No new dependency, no orchestrator contract change.

Testing

• SchemaCache: rendering isolation, no 1/11 confusion, TTL per key, entriesForRendering scoping.
• SchemaResolver: regression test — rendering B fetches its own schema instead of reusing rendering A's cached one.
• AgentClientAgentPort + 8 executor tests updated to the new signatures.
• 1002 tests pass, lint clean, build green.

fixes PRD-440

🤖 Generated with Claude Code

Note

Scope workflow-executor collection schema cache by rendering ID

• SchemaCache now stores entries keyed by renderingId + collectionName composite key; get, set, and the new entriesForRendering method all require a renderingId, isolating cached schemas per rendering.
• SchemaResolver accepts and stores a renderingId, passing it through to all cache reads and writes so resolvers never reuse schemas from other renderings.
• AgentClientAgentPort.buildActionEndpoints now accepts a renderingId and iterates only over cache entries for that rendering, so action endpoints are scoped to the current user's rendering.
• Behavioral Change: cache entries that were previously shared across all renderings are now isolated; any code constructing SchemaCache, SchemaResolver, or calling buildActionEndpoints must supply a renderingId.

^{Macroscope summarized f388e5f.}

[linear-code]

PRD-440

[qltysh]

1 new issue

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

[qltysh]

Coverage Impact

This PR will not change total coverage.

Modified Files with Diff Coverage (4)

Rating	File	% Diff	Uncovered Line #s
	packages/workflow-executor/src/executors/step-executor-factory.ts	100.0%
	packages/workflow-executor/src/schema-cache.ts	100.0%
	...ages/workflow-executor/src/adapters/agent-client-agent-port.ts	100.0%
	packages/workflow-executor/src/schema-resolver.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.