🐛 fix(api): report the real server version in portwing WS welcome frames#553
Merged
Conversation
drydockVersion() claimed to read package.json at runtime but hard-coded '1.5.0' since the endpoint shipped in v1.5.0 — every welcome frame on v1.5.1/v1.5.2/v1.6.0-rc.1 identified the server as 1.5.0 to agents. It now delegates to the canonical getVersion() (DD_VERSION override, else package.json), still cached and still overridable by injectDrydockVersionForTesting(). Found by CodeRabbit on release PR #550 against the documented welcome example. 🧪 TDD: regression test mocks getVersion() and asserts the welcome frame carries it (failed pre-fix expecting '9.9.9-test', received '1.5.0'); 98/98 file tests green post-fix. 📝 CHANGELOG bullet under [1.6.0-rc.2] Fixed.
scttbnsn
requested review from
ALARGECOMPANY and
biggest-littlest
as code owners
July 17, 2026 07:18
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe WebSocket gateway now obtains its cached 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/api/portwing-ws.test.ts`:
- Around line 347-350: Replace the fixed 10 ms timeout after
sendMessageToGateway in the websocket test with the gateway’s message/event
completion signal or the existing bounded frame-wait helper. Ensure the welcome
frame is available before reading ws.sentMessages[0], while retaining a bounded
wait to avoid hanging tests.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 3376ee25-ba9b-4fc0-9a3c-b57a914c4336
⛔ Files ignored due to path filters (1)
CHANGELOG.mdis excluded by!CHANGELOG.md
📒 Files selected for processing (2)
app/api/portwing-ws.test.tsapp/api/portwing-ws.ts
CodeRabbit follow-up on PR #553: replace the fixed 10 ms sleep with vi.waitFor so the welcome read isn't scheduler-dependent under CI load.
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
1 participant
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.
Fixes the shipped bug CodeRabbit caught on release PR #550 (the finding):
drydockVersion()claimed to be populated from package.json at runtime but hard-coded'1.5.0'— every portwing WS Welcome frame since the endpoint shipped in v1.5.0 (so v1.5.1, v1.5.2, and v1.6.0-rc.1 servers) identified itself as1.5.0to agents. The documented Welcome example was describing intended behavior the code never delivered.Fix:
drydockVersion()now delegates to the canonicalgetVersion()fromapp/configuration(DD_VERSIONoverride, else package.json — the same sourceapp/debug/dump.tsand the rest of the API use), still cached at first read and still overridable byinjectDrydockVersionForTesting(). Stale comments corrected.TDD (Codex tests first): new regression test mocks
getVersion()to a sentinel and asserts the Welcome frame carries it — failed pre-fix withexpected '1.5.0' to be '9.9.9-test'; 98/98 file tests green post-fix,portwing-ws.tsat 100/100/100/100.CHANGELOG bullet under
[1.6.0-rc.2]Fixed. Full pre-push gate green from a worktree; release-guard scripts 105/105.Changelog
🐛 Fixed
1.5.0).drydockVersion()delegates to the canonicalgetVersion()fromapp/configuration(honorsDD_VERSIONoverride orpackage.jsonfallback) while keeping first-read caching and the existinginjectDrydockVersionForTesting()override.[1.6.0-rc.2]changelog entry to reflect the Portwing WS welcome-version fix.🔧 Changed
getVersion()and assert the first outboundwelcomeframe containsdata.config.drydockVersionequal to the mocked value during a full upgrade + hello handshake.vi.waitFor.