Repository navigation
fix(coordination): the workflow spec SDK compiles a validator on first use, not when imported - #308
Merged
rami-hatoum merged 1 commit intoOct 23, 2026
Conversation
…t use, not when it is imported `@openworkflowspec/sdk` 1.0.3-alpha8 builds an Ajv instance and compiles all 171 of its validators as it is imported, which generates 217 functions from strings. The runtime never asks the SDK to validate: the capability checks a document with an interpreting validator and keeps the SDK for its classes and its graph. A library that compiles what nobody asks for, at import, has the defect, and the fix is the library's; until it ships, the runtime carries it as a dependency patch. - `patches/@openworkflowspec__sdk@1.0.3-alpha8.patch`, named in `pnpm-workspace.yaml`, makes `index.mjs`, `index.cjs` and `index.umd.js` build the Ajv instance and compile the validator of a type the first time `validate` asks for that type, and keep it. The errors for a type the SDK does not know and for a schema it cannot find stay. `index.umd.min.js`, which Node does not load, is left as published. - The image copies `patches/` before it installs its dependencies, whose install otherwise stops with "Patch file not found". - A test runs a child Node process with `--disallow-code-generation-from-strings`: the SDK loads, hydrates a workflow, builds its graph and writes its Mermaid as it does without the flag, and only `validate` is refused. Without the patch the child cannot import the SDK and the test fails. - The capability's README says the SDK is patched, why, what the minified bundle and the npm package get, and that the patch goes when the SDK itself compiles on first use. - The coordination and tool-servers READMEs say what the first save of a workflow costs with the SDK patched, measured again and dated, beside what it cost as published. Patched, the import generates no function from strings and the first `validate` of a workflow 47. The import took 19 ms against 119 ms as published, at the median of 11 imports of each, and the first save of a workflow without expressions 82 ms, against 182 ms as published and 37 ms when the SDK loaded at the start, at the median of 9 servers of each; each interleaved, with Node 26.10.0 on one machine of 16 cores at a load average of 5.5 to 6.6. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
rami-hatoum
deleted the
fix/the-workflow-spec-sdk-compiles-a-validator-on-first-use
branch
October 23, 2026 18:42
rami-hatoum
pushed a commit
that referenced
this pull request
Oct 23, 2026
🤖 I have created a release *beep* *boop* --- ## [0.18.0](v0.17.0...v0.18.0) (2026-10-23) ### Features * **identity:** keys from a key source, a person without an org acts in their own, a key set given ([#301](#301)) ([ca6f754](ca6f754)) * **server:** the npm package carries every package as a subpath, with its testing entry ([#304](#304)) ([caf2e36](caf2e36)) ### Bug Fixes * **coordination:** the workflow spec SDK compiles a validator on first use, not when imported ([#308](#308)) ([0dcd0df](0dcd0df)) * **workflow-host:** the follower notes each unreadable record, and a first follow misses nothing ([#302](#302)) ([7c5588c](7c5588c)) * **workflow-host:** the waiting measurement names the run of each record it writes ([#299](#299)) ([69ad59f](69ad59f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: beonautobot[bot] <298957281+beonautobot[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
@openworkflowspec/sdkbuilds an Ajv instance over its schema and compiles all 171 of its validators the moment it is imported, generating code from strings, though the runtime never asks it to validate: the coordination capability checks a document with an interpreting validator and uses the SDK for its classes and its graph alone. A library that compiles what nobody asks for, at import, is a defect of the library, and the fix is the library's, compiling a validator the first timevalidateis called for a type; it is offered upstream asopen-workflow-specification/sdk-typescript#333. Until the library ships it, the runtime carries it as a dependency patch, byte-identical to the one Studio carries, named in the workspace and copied into the container image before its install.Measured on a quiet machine: importing the SDK took 119 ms of wall time and 174 ms of CPU as published, 19 ms and 28 ms patched, generating 217 functions as published and none patched; the first workflow save, which now loads the SDK, takes 82 ms against 182 ms with the SDK as published; the second save is unchanged. The coordination and tool-servers READMEs carry the figures with their dates; the minified browser bundle is left as published.
Tests
validatethrows; without the patch the import itself fails.pnpm checkpasses.