test(mcp): resolve module-path expectations portably - #13779
Conversation
The resolveServerModulePath tests stubbed the filesystem with POSIX string literals while the resolver builds candidates with path.resolve — which on the release workflow's Windows leg yields drive-qualified backslash paths (C:\var\task\src\crm.mjs), so no candidate ever matched the stub and all six tests threw the not-in-package error. First contact between these tests and Windows: the cross-platform matrix runs only in the release workflow, which no PR CI exercises. The stub keys and the expectations are now built with the same path.resolve call the resolver uses, so the assertions hold on every runner. Product code is untouched — the entry only ever runs on Lambda's Linux.
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe MCP compose unit tests now compute expected filesystem paths with ChangesMCP path resolution tests
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
packages/serverless/test/unit/lib/plugins/aws/mcp/entry/compose.test.jsESLint skipped: missing config or dependency (missing-dependency). The ESLint configuration references a package that is not available in the sandbox. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
The release workflow's Windows leg fails on six
resolveServerModulePathtests incompose.test.js: the tests stub the filesystem with POSIX string literals (/var/task/src/crm.mjs), while the resolver builds candidates withpath.resolve— which on Windows yields drive-qualified backslash paths (C:\var\task\src\crm.mjs). No candidate ever matches the stub, so all six tests throw the not-in-package error.Failing run: https://github.com/serverless/serverless/actions/runs/31014879879/job/92336224583
Test-only change — product code is untouched. The MCP entry executes only on Lambda's Linux runtime; the failures are pure test portability. The stub keys and the expectations are now built with the same
path.resolve('/var/task', …)call the resolver uses, so the assertions hold on every runner by construction.Why this surfaced only post-merge: the cross-platform matrix (Windows/arm) runs only in
Release: Framework CLI, which no PR CI exercises — this was the suite's first contact with Windows. The Windows job ran the full 186-suite fleet and this was the only failure.Impact
release-canaryneeds: [test-matrix, test-engine], so the failing leg blocked the release cleanly — nothing was published. Merging this unblocks the release train.Testing
compose.test.js57/57 green on POSIX; the win32 resolution shape was probed explicitly to confirm the mismatch mechanism and that the fix keys both sides on the same call.Summary by CodeRabbit