Stub both poll routes so the test doesn't pin an SDK detail#17
Merged
Conversation
Two cases stubbed GET /bulk/{id} because that is where the SDK's getJob
happened to look. That is the SDK's implementation detail, not this
layer's contract — and it just moved to the kind-agnostic /jobs/{id}.
These tests are about the MCP layer's structured output, so pinning one
path made them fail on an SDK upgrade that changed nothing here.
Stub both, and they pass against either SDK version.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Small follow-up to #16, which merged while the SDK change below was in flight.
Two cases in
test/structured-output.test.mjsstubGET /bulk/{id}because that's where the SDK'sgetJobhappened to look. That's the SDK's implementation detail, not this layer's contract — and it just moved to the kind-agnosticGET /jobs/{id}(WellMarkedAPI/JS-TS-SDK#12, which requires WellMarkedAPI/WellMarked#192).These tests are about the MCP layer's structured output, not the SDK's routing, so pinning one path made them fail on an SDK upgrade that changed nothing here. I hit exactly that: after rebuilding against the local SDK,
get_job returns job state as real JSON typesanda finished job with no results still validatesboth failed withCannot read properties of undefined (reading 'kind')— the stub missed, the tool returnedisError, andstructuredContentwas absent.Stubbing both paths makes them pass against either SDK version.
Verified:
npm test→ 11/11 against the local SDK build (which calls/jobs/{id}). They also still pass against the publishedwellmarked@1.1.1(which calls/bulk/{id}) — that's the point of stubbing both.No production code changes.
🤖 Generated with Claude Code