test: align read_file image-content assertions with #488#493
Conversation
#488 added the image bytes back into read_file's MCP `content` array so the host model can see images, but test-file-handlers.js was never updated and still asserted the pre-#488 contract ("avoid image content item for host compatibility"). That assertion is now inverted from the shipped behaviour and was the only failing test in the suite. Update Test 9 to assert the current contract for both raster (PNG) and SVG reads: the `content` array includes an `image` item carrying base64 `data` and the correct `mimeType` (image/png, image/svg+xml), alongside the existing structuredContent checks. No production code change — handler behaviour is unchanged.
|
Caution Review failedPull request was closed or merged during review No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughTest assertions for image file preview metadata are updated to expect ChangesImage preview content assertions
Estimated code review effort🎯 2 (Simple) | ⏱️ ~5 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
What
Fixes the only failing test in the suite (
test/test-file-handlers.js, Test 9).Why
#488 intentionally added the image bytes back into
read_file's MCPcontentarray so the host model can actually see images. The test was never updated and still asserted the pre-#488 contract:That assertion is now inverted from shipped behaviour, so the suite went red (39/40). This is a stale test, not a regression.
Change
Test 9 now asserts the current contract for both raster (PNG) and SVG reads: the
contentarray includes animageitem carrying non-empty base64dataand the correctmimeType(image/png,image/svg+xml), alongside the existingstructuredContentchecks (which were already correct).No production code changes — handler behaviour is unchanged.
Note / open question
.svgis routed throughImageFileHandler(isImage: true), soread_fileon an SVG emits an MCPimagecontent block withmimeType: image/svg+xml. Not every host renders SVG image blocks, and SVG is also readable as text. This PR matches the current handler behaviour; if SVG should fall through to the text branch instead, that's a handler-side decision and a separate change.Test
Summary by CodeRabbit