Uh oh!
There was an error while loading. Please reload this page.
fix: use workflow health endpoint to check for port - #616
Merged
Conversation
🦋 Changeset detectedLatest commit: fa8510e 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
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (11 failed)mongodb (1 failed):
redis (1 failed):
starter (8 failed):
turso (1 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
|
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro workflow with 10 parallel steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro stress test: Promise.all with 100 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) stress test: Promise.race with 100 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Stream Benchmarks(includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
Contributor
There was a problem hiding this comment.
Additional Suggestion:
The JSDoc comment for the probePort function is outdated and doesn't match the implementation. It claims the function returns true for "non-404 response" but the code now checks for exactly 200 status.
View Details
📝 Patch Details
diff --git a/packages/utils/src/get-port.ts b/packages/utils/src/get-port.ts
index d4c4a28..24dca4a 100644
--- a/packages/utils/src/get-port.ts+++ b/packages/utils/src/get-port.ts@@ -248,7 +248,7 @@ export interface ProbeOptions {
* Probes a port to check if it's serving the workflow HTTP server.
* Uses HEAD request to minimize overhead.
*
- * @returns true if the port responds as a workflow server (non-404 response)+ * @returns true if the port responds with a 200 status from the health check endpoint
*/
async function probePort(
port: number,
Analysis
Outdated JSDoc comment in probePort() function doesn't match implementation
What fails: The JSDoc comment at line 251 of packages/utils/src/get-port.ts claims the probePort() function @returns true if the port responds as a workflow server (non-404 response), but the actual implementation at line 269 explicitly checks return response.status === 200;
How to reproduce:
- Read the JSDoc comment for
probePort()function inpackages/utils/src/get-port.ts(line 251) - Read the implementation at lines 268-269
- Observe the mismatch: the comment says "non-404 response" but code checks for exactly status 200
What happened vs expected behavior:
- The code behavior was changed in commit
34cb235(Dec 15, 2025) from checkingresponse.status !== 404to checkingresponse.status === 200 - The internal code comments were updated in commit
5840ab2, but the JSDoc was left outdated - Developers reading the JSDoc would incorrectly believe the function accepts any non-404 response (400, 405, etc.) when it actually requires exactly 200
Fix: Updated the JSDoc @returns line to accurately reflect the implementation: @returns true if the port responds with a 200 status from the health check endpoint
Verification: All 19 tests in packages/utils/src/get-port.test.ts pass with the updated documentation.
…oesn't match the implementation. It claims the function returns true for "non-404 response" but the code now checks for exactly 200 status. This commit fixes the issue reported at packages/utils/src/get-port.ts:251 ## Outdated JSDoc comment in probePort() function doesn't match implementation **What fails:** The JSDoc comment at line 251 of `packages/utils/src/get-port.ts` claims the `probePort()` function `@returns true if the port responds as a workflow server (non-404 response)`, but the actual implementation at line 269 explicitly checks `return response.status === 200;` **How to reproduce:** 1. Read the JSDoc comment for `probePort()` function in `packages/utils/src/get-port.ts` (line 251) 2. Read the implementation at lines 268-269 3. Observe the mismatch: the comment says "non-404 response" but code checks for exactly status 200 **What happened vs expected behavior:** - The code behavior was changed in commit `34cb235` (Dec 15, 2025) from checking `response.status !== 404` to checking `response.status === 200` - The internal code comments were updated in commit `5840ab2`, but the JSDoc was left outdated - Developers reading the JSDoc would incorrectly believe the function accepts any non-404 response (400, 405, etc.) when it actually requires exactly 200 **Fix:** Updated the JSDoc `@returns` line to accurately reflect the implementation: `@returns true if the port responds with a 200 status from the health check endpoint` **Verification:** All 19 tests in `packages/utils/src/get-port.test.ts` pass with the updated documentation. Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
TooTallNate
commented
Dec 16, 2025
Member
@ijjk Would this cause a problem with the lazy bundling that you're thinking of implementing? |
ijjk
approved these changes
Dec 16, 2025
Member
This shouldn't cause a conflict with that no |
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
instead of pinging the flow workflow endpoint to check for port and looking for non-404s, we ping the health check endpoint for workflow at
http://localhost:${PORT}/.well-known/workflow/v1/flow?__healthfor 200