[core] Surface workflowCoreVersion from healthCheck() result#1854
Open
TooTallNate wants to merge 4 commits intomainfrom
Open
[core] Surface workflowCoreVersion from healthCheck() result#1854TooTallNate wants to merge 4 commits intomainfrom
TooTallNate wants to merge 4 commits intomainfrom
Conversation
The responding deployment already advertises its `@workflow/core` version
on the wire via `handleHealthCheckMessage` (`helpers.ts:109`), but it was
dropped at the parsing step. Surface it on `HealthCheckResult` so
callers can derive capability metadata about a target deployment before
sending it work — for example, version-gated decisions via
`getRunCapabilities()`.
Backwards compatible:
- Older deployments with plain-text health responses (specVersion < 3)
yield `{ healthy: true }` with no version metadata, as before.
- Older deployments with JSON responses but no `workflowCoreVersion`
field continue to return `{ healthy, specVersion? }`; the field is
simply omitted from the result.
- Defensive type check rejects non-string values rather than passing
them through as garbage.
Tests cover all four cases (workflowCoreVersion present, missing,
wrong type, plain-text legacy response) via a small in-memory mock
world plus a new e2e assertion.
🦋 Changeset detectedLatest commit: 415fd16 The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
Contributor
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests💻 Local Development (2 failed)vite-stable (2 failed):
🐘 Local Postgres (2 failed)astro-stable (2 failed):
Details by Category❌ 💻 Local Development
✅ 📦 Local Production
❌ 🐘 Local Postgres
✅ 📋 Other
❌ Some E2E test jobs failed:
Check the workflow run for details. |
Contributor
📊 Benchmark Resultsworkflow with no steps💻 Local Development
workflow with 1 step💻 Local Development
workflow with 10 sequential steps💻 Local Development
workflow with 25 sequential steps💻 Local Development
workflow with 50 sequential steps💻 Local Development
Promise.all with 10 concurrent steps💻 Local Development
Promise.all with 25 concurrent steps💻 Local Development
Promise.all with 50 concurrent steps💻 Local Development
Promise.race with 10 concurrent steps💻 Local Development
Promise.race with 25 concurrent steps💻 Local Development
Promise.race with 50 concurrent steps💻 Local Development
workflow with 10 sequential data payload steps (10KB)💻 Local Development
workflow with 25 sequential data payload steps (10KB)💻 Local Development
workflow with 50 sequential data payload steps (10KB)💻 Local Development
workflow with 10 concurrent data payload steps (10KB)💻 Local Development
workflow with 25 concurrent data payload steps (10KB)💻 Local Development
workflow with 50 concurrent data payload steps (10KB)💻 Local Development
Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
stream pipeline with 5 transform steps (1MB)💻 Local Development
10 parallel streams (1MB each)💻 Local Development
fan-out fan-in 10 streams (1MB each)💻 Local Development
SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
Contributor
There was a problem hiding this comment.
Pull request overview
Surfaces the responding deployment’s @workflow/core version (workflowCoreVersion) on the HealthCheckResult returned by healthCheck(), enabling downstream capability detection (e.g., via getRunCapabilities()) in cross-deployment scenarios.
Changes:
- Extend
HealthCheckResultandparseHealthCheckResponse()to extract and propagateworkflowCoreVersionwhen it is a string. - Add unit tests covering present/missing/wrong-type/legacy plain-text responses for health check parsing.
- Strengthen e2e assertions to verify
workflowCoreVersionis present on queue-based health checks.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| packages/core/src/runtime/helpers.ts | Adds workflowCoreVersion to the public health check result and parses it from JSON responses. |
| packages/core/src/runtime/helpers.test.ts | Adds focused unit tests for healthCheck() parsing behavior around workflowCoreVersion. |
| packages/core/e2e/e2e.test.ts | Ensures e2e health checks assert workflowCoreVersion is present and a string. |
| .changeset/healthcheck-coreversion.md | Publishes the API surface change as a patch for @workflow/core and workflow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The JSDoc on HealthCheckResult.workflowCoreVersion and the test names implied a specVersion < 3 → plain-text-response → no version-field chain that doesn't actually hold. The field is omitted whenever the responder doesn't provide it as a string, regardless of specVersion. Reword the docs and test names accordingly.
Surfacing a new field on the public HealthCheckResult interface is an additive API change, semver-minor rather than patch.
3 tasks
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.
Summary
Surface the responding deployment's
@workflow/coreversion on theHealthCheckResultreturned byhealthCheck(). The field is already advertised on the wire byhandleHealthCheckMessage(helpers.ts:109) but was dropped at the parse step.This unlocks pre-flight capability detection for cross-deployment scenarios, where the caller needs to know what a target deployment supports before sending it work — e.g. version-gated decisions via
getRunCapabilities().Diff
parseHealthCheckResponsenow extracts the field if it's a string, drops it otherwise.healthCheck()propagates it onto the result.Backwards compatibility
{ healthy: true }with no version metadata, same as before.workflowCoreVersionfield continue to return{ healthy, specVersion? }; the field is simply omitted.Tests
helpers.test.ts, 4 new): version present / missing / wrong-type / plain-text legacy response, via a small in-memory mock world that simulateshandleHealthCheckMessagewriting the response onto a stream.e2e.test.ts): the existing health check test now assertstypeof workflowResult.workflowCoreVersion === 'string'against the deployed app, so the end-to-end wire propagation is verified.All 595 core unit tests pass.
Related
PR #1853 (byte-stream framing) builds on this — the cross-deployment
start()probe needsworkflowCoreVersionto derive whether the target deployment can decode framed byte streams. That PR will be rebased onto this one once it lands.🤖 Generated with Claude Code