Repository navigation
DX-3022: mcp-toolkit: isError fails the task, keep failure details from the model - #62
Merged
Merged
Conversation
…om the model; README matches the docs
- A handler returning { isError: true } now settles the task failed (no retry); task_status returns its content with isError, as the synchronous tool would
- structuredContent carries only error.code and error.message: error.data (DLQ id, the failing response, Workflow's failResponse) stays in the store
- A dispatch failure is logged and answered with a generic tool error instead of rethrowing the transport's message
- README: lib/auth.ts with verifyToken + principal, mcp-handler withMcpAuth route, QSTASH_URL; changeset mentions the failure behavior
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gtucop3k8CNVLjgvoDTC8n
…re what the handler threw - Client.trigger turns workflowRunId into wfr_<id> but Client.cancel takes the id as is, so cancel sent the bare task id and matched no run: the run kept executing. Cancel now sends runIdOf(taskId). - Tested against the real @upstash/workflow client with fetch stubbed (fails on the old code), not a stubbed client. - failureFunction logs failResponse (the thrown error's message) instead of storing it in error.data, so it reaches neither Redis nor, via task_status, the task's owner. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gtucop3k8CNVLjgvoDTC8n
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gtucop3k8CNVLjgvoDTC8n
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.
Follow-up to #38, before the first
@upstash/mcp-toolkitrelease.Tasks
{ isError: true }now settles the taskfailed, with no retry.task_statusreturns the handler's content withisError, the same as the synchronous tool would. Before this, the task readcompletedandisErrorwas dropped.structuredContentnow carries onlyerror.codeanderror.message.error.data(the DLQ id, the failing response, Workflow'sfailResponse) stays in Redis and is no longer sent to the model.Workflow dispatcher
task_cancelnow actually cancels the run.Client.triggerturns theworkflowRunIdit's given intowfr_<id>, butClient.canceltakes the id as is. So we were triggeringwfr_<uuid>and cancelling<uuid>, which matched no run, and the failure was silent. The task record readcancelled, but every remaining step and side effect still ran. Cancel now sendswfr_<taskId>. The new test uses the real@upstash/workflowclient with onlyfetchstubbed, and fails on the old code.failureFunctionnow logsfailResponse(the message of the error the handler threw) instead of storing it inerror.data, so it never reaches Redis or the task's owner. Checked end to end: before this change, failed Workflow tasks in Redis held the exception text; after it, they hold only the run id.README now matches the docs and the blog:
lib/auth.tsholdsverifyTokennext toprincipal, the route usesmcp-handler'swithMcpAuth, andQSTASH_URLis listed.Changeset: the unreleased
mcp-toolkit-initialentry now mentions the failure behavior, so the "Version Packages" PR (#61) picks it up.Checked: lint, typecheck (mcp-toolkit and the demo), 134/134 tests including the Redis-backed suites, and the demo's e2e run on both the QStash and Workflow servers.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Gtucop3k8CNVLjgvoDTC8n