feat(workflow-executor): serialize recordId as pipe string at front/orchestrator boundaries

[Scra3]

Summary

• Adds serializeRecordId / deserializeRecordId utility in src/adapters/record-id-serializer.ts
• Applies deserialization in run-to-available-step-mapper.ts: splits pipe-separated selectedRecordId from the orchestrator into a proper array ('id1|id2' → ['id1', 'id2'])
• Applies serialization in executor-http-server.ts via src/http/step-serializer.ts: converts recordId arrays to pipe strings in GET /runs/:runId responses (['id1', 'id2'] → 'id1|id2')
• Applies deserialization in pending-data-validators.ts: accepts selectedRecordId as a pipe string from POST trigger body and transforms to array

Test plan

• record-id-serializer.test.ts — unit tests for the two utility functions
• run-to-available-step-mapper.test.ts — new test for composite key 'pk1|pk2' → ['pk1', 'pk2']
• executor-http-server.test.ts — serialization tests for update-record and load-related-record steps
• pending-data-validators.test.ts — deserialization tests for pipe-string selectedRecordId

788 tests passing.

fixes PRD-214

🤖 Generated with Claude Code

Note

Serialize RecordId as a pipe-separated string at workflow executor HTTP and orchestrator boundaries

• Introduces serializeRecordId and deserializeRecordId utilities in record-id-serializer.ts to convert between RecordId arrays and pipe-joined strings (e.g. 'a|b').
• The GET /runs/:runId response now serializes all recordId fields (selected record refs, load-related-record candidates, suggested records, and execution results) to pipe-separated strings via step-serializer.ts.
• POST /runs/:runId/trigger now expects selectedRecordId as a pipe-separated string and deserializes it into an array, validated in pending-data-validators.ts.
• Step executors (load-related-record, read-record, update-record, trigger-action) now pass the full RecordId array to activity log args instead of only the first segment; the activity log adapter serializes it to a pipe string before sending.
• toAvailableStepExecution in run-to-available-step-mapper.ts now throws InvalidStepDefinitionError when selectedRecordId is missing or empty, and deserializes the pipe string into an array.
• Behavioral Change: composite record IDs previously truncated to their first segment are now fully preserved across the HTTP boundary.

^{Macroscope summarized eabb6ec.}

[linear]

PRD-214

PRD-399

[qltysh]

Coverage Impact

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

Modified Files with Diff Coverage (6)

Rating	File	% Diff	Uncovered Line #s
	...-executor/src/adapters/forestadmin-client-activity-log-port.ts	100.0%
	packages/workflow-executor/src/http/pending-data-validators.ts	100.0%
	packages/workflow-executor/src/http/executor-http-server.ts	100.0%
	packages/workflow-executor/src/adapters/record-id-serializer.ts	100.0%
	...workflow-executor/src/adapters/run-to-available-step-mapper.ts	100.0%
	packages/workflow-executor/src/http/step-serializer.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.

[Scra3]

https://linear.app/forestadmin/issue/PRD-399/refactor-align-front-end-composite-key-handling-with-executor-pipe

[macroscopeapp]

🟡 Medium http/pending-data-validators.ts:47

deserializeRecordId returns string[] but is typed as Array<string | number>, and downstream code may perform strict equality checks like selectedId === record.id where record.id is a number. The comparison fails because "123" !== 123, breaking record matching. Consider updating deserializeRecordId to coerce numeric-looking strings to numbers so the runtime values match the declared type and existing numeric IDs.

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

In file packages/workflow-executor/src/http/pending-data-validators.ts around line 47:

`deserializeRecordId` returns `string[]` but is typed as `Array<string | number>`, and downstream code may perform strict equality checks like `selectedId === record.id` where `record.id` is a number. The comparison fails because `"123" !== 123`, breaking record matching. Consider updating `deserializeRecordId` to coerce numeric-looking strings to numbers so the runtime values match the declared type and existing numeric IDs.

Evidence trail:
packages/workflow-executor/src/adapters/record-id-serializer.ts:5-6 — `deserializeRecordId` calls `value.split('|')` (always returns `string[]`) with return type `Array<string | number>`. packages/workflow-executor/src/adapters/record-id-serializer.ts:1-3 — `serializeRecordId` takes `Array<string | number>` and `.map(String).join('|')`, showing the round-trip is not type-preserving. packages/workflow-executor/src/http/pending-data-validators.ts:47 — Zod transform uses `deserializeRecordId`. packages/workflow-executor/src/executors/load-related-record-step-executor.ts:321-340 — downstream usage assigns result to `RecordRef.recordId` typed as `Array<string | number>` but never compares via `===`. git_grep for `recordId.*(find|includes|some|indexOf|===)` returned zero matches in `packages/workflow-executor/src/**`.