fix: Set final statusMessage before storeTaskResult (#638) by jirispilka · Pull Request #680 · apify/apify-mcp-server

jirispilka · 2026-04-15T14:25:12Z

Summary

Fixes #638 — tasks/list shows stale statusMessage (e.g. "Starting the crawler.") for completed tasks because storeTaskResult() doesn't accept a statusMessage parameter.

Changes:

Add storeTaskResultWithMessage() helper in src/mcp/utils.ts — encapsulates the SDK workaround (updateTaskStatus + storeTaskResult in sequence)
Set correct final statusMessage per outcome in executeToolAndUpdateTask:
- SUCCEEDED → "tool: completed"
- SOFT_FAIL → "[error] tool: Actor not found…" (with [error] prefix)
- Pre-flight 402 → "[error] tool: payment required"
- Catch-block 402 → "[error] tool: payment required" + isTaskCancelled guard
- Catch-block error → "[error] tool: error text… (truncated)" if >200 chars
- ABORTED (signal) → transition to cancelled (was incorrectly stored as completed with empty {} result)
Cancel message includes tool/actor prefix when available (e.g. "apify/rag-web-browser: cancelled by client")

SDK workaround — all results stored as 'completed':

The MCP SDK's requestStream() only calls getTaskResult() for 'completed' tasks. For 'failed' tasks it yields a generic "Task X failed" error and discards the stored result. This means:

x402 auto-pay retry breaks (client never sees the payment payload)
Error details are lost (client gets generic message instead of actual error text)

We work around this by storing all results as 'completed' and using [error] prefix in statusMessage to signal the real outcome. Full analysis in res/task_status_workaround.md.

Verified with mcpc

Path	Result delivered?	`isError`	`tasks-list` status	`statusMessage`
Success (actor completes)	yes	`null`	`completed`	`call-actor: completed`
Actor not found (soft-fail)	yes, error text	`true`	`completed`	`[error] call-actor: Actor not found…`
Input validation (soft-fail)	yes, error text	`true`	`completed`	`[error] call-actor: Input validation failed…`
Cancel (before progress)	N/A	N/A	`cancelled`	`Cancelled by client`
Cancel (after progress)	N/A	N/A	`cancelled`	`apify/google-search-scraper: cancelled by client`
Cancel completed (409)	rejected	N/A	unchanged	unchanged

Follow up issues

Test plan

npm run type-check — zero errors
npm run lint — zero errors
npm run test:unit — 488 tests pass
mcpc: success path — result delivered, statusMessage: "call-actor: completed"
mcpc: soft-fail — result delivered with isError: true, statusMessage has [error] prefix
mcpc: cancel — correct cancelled status with tool prefix when available
mcpc: cancel completed task — 409 rejection
npm run test:integration

🤖 Generated with Claude Code

storeTaskResult() has no statusMessage parameter, so the last intermediate progress message (e.g. "Starting the crawler.") persisted as the final statusMessage on completed/failed tasks. Call updateTaskStatus() with a descriptive final message right before each storeTaskResult() call. https://claude.ai/code/session_01ABYjPsZxtCdib54jfGcx3f

The third test asserted that a stale intermediate statusMessage is preserved through storeTaskResult — which tests InMemoryTaskStore internals, not the bug. The two remaining cases are sufficient regression coverage.

…torage

The MCP SDK's requestStream() only calls getTaskResult() for 'completed' tasks — 'failed' tasks yield a generic "Task X failed" error and discard the stored result. This broke x402 auto-pay retry (client never saw the payment payload) and lost error details for soft-fail results. - Revert task status from 'failed' back to 'completed' for all result paths - Add [error] prefix to statusMessage so tasks/list shows the real outcome - Add "… (truncated)" suffix when statusMessage is clipped to 200 chars - Document the workaround and upstream fixes needed in res/task_status_workaround.md Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

jirispilka · 2026-04-16T10:26:40Z

@claude can you review again

Copilot

Pull request overview

Fixes stale statusMessage for terminal tasks by ensuring a final message is written immediately before persisting the task result, along with documenting (and testing) the SDK-driven workaround for result delivery.

Changes:

Added storeTaskResultWithMessage() helper to update final statusMessage then store the result.
Updated executeToolAndUpdateTask() to set outcome-specific final messages and to mark signal aborts as cancelled.
Added unit + integration regression tests and documentation for the “store errors as completed” workaround.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
`src/mcp/utils.ts`	Adds `storeTaskResultWithMessage()` helper for final statusMessage + result persistence.
`src/mcp/server.ts`	Uses helper to set final messages; adjusts cancellation messaging and terminal handling.
`tests/unit/task.statusMessage.test.ts`	New unit regression coverage for final `statusMessage` behavior.
`tests/unit/server.task_execution.test.ts`	Verifies task-mode soft-fail payloads are stored/delivered.
`tests/integration/suite.ts`	Integration regression test ensuring success ends with `: completed`.
`res/task_status_workaround.md`	Documents why errors are stored as `completed` due to SDK `requestStream()` behavior.
`res/index.md`	Index entry for the new workaround doc.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

… logging

…rrors

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

… messaging

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 5 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

jirispilka · 2026-04-16T12:21:41Z

@copilot apply changes based on the comments in this thread

Agent-Logs-Url: https://github.com/apify/apify-mcp-server/sessions/b6debe5d-50b7-4b92-9b85-8ab365c2df09 Co-authored-by: jirispilka <19406805+jirispilka@users.noreply.github.com>

Copilot · 2026-04-16T12:30:58Z

@copilot apply changes based on the comments in this thread

Done in 558070b. I applied the thread feedback: narrowed storeTaskResultWithMessage() to completed-only, changed safeStoreResult() to rethrow non-cancellation storage errors, renamed the misleading unit-test helper, and aligned the task request tool name with call-actor in the execution test.

…dling continues

…accordingly

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

src/mcp/server.ts:1147

finishTaskTracking logs toolName: tool.name, while status messages and telemetry initialization use toolFullName (canonical tool/actor name). This can make task-mode logs inconsistent with non-task mode (e.g. actor tools logging the encoded tool name rather than apify/<actor>). Consider passing toolFullName into logToolCallAndTelemetry here for consistency.

        const finishTaskTracking = (status: ToolStatus, diagnostics?: CallDiagnostics) => {
            this.logToolCallAndTelemetry({
                toolName: tool.name,
                mcpSessionId,
                toolStatus: status,

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-16T15:57:58Z

+export async function storeTaskResultWithMessage(
+    taskStore: TaskStore,
+    taskId: string,
+    // Always 'completed' — the SDK's requestStream() only delivers results for 'completed' tasks;
+    // 'failed' tasks yield a generic error and discard the stored result. See res/task_status_workaround.md.
+    status: 'completed',
+    result: Result,


storeTaskResultWithMessage requires callers to pass a status: 'completed' argument even though the type only permits 'completed' and the function comment states it’s always completed. Dropping the parameter (or renaming it to something like completedStatus is unnecessary) would reduce call-site noise and prevent the API from looking more flexible than it is.

Copilot · 2026-04-16T15:57:59Z

        process.exit(1);
    }

+    log.setLevel(process.env.LOG_LEVEL === 'info' ? log.LEVELS.INFO : log.LEVELS.DEBUG);


This LOG_LEVEL handling only distinguishes 'info' vs “everything else → debug”. Since the repo already defines LOG_LEVEL_MAP (debug/info/notice/…/emergency), consider reusing it here so LOG_LEVEL=error (etc.) behaves as expected in dev mode, and default to a sensible level when unset.

Suggested change

log.setLevel(process.env.LOG_LEVEL === 'info' ? log.LEVELS.INFO : log.LEVELS.DEBUG);

const configuredLogLevel = (process.env.LOG_LEVEL ?? 'debug').trim().toUpperCase() as keyof typeof log.LEVELS;

const resolvedLogLevel = configuredLogLevel in log.LEVELS

? log.LEVELS[configuredLogLevel]

: log.LEVELS.DEBUG;

log.setLevel(resolvedLogLevel);

github-actions bot assigned jirispilka Apr 15, 2026

github-actions bot added t-ai Issues owned by the AI team. tested Temporary label used only programatically for some analytics. labels Apr 15, 2026

jirispilka mentioned this pull request Apr 15, 2026

fix: set final statusMessage before storeTaskResult (#638) #677

Closed

2 tasks

jirispilka changed the title ~~fix: set final statusMessage before storeTaskResult (#638)~~ fix: Set final statusMessage before storeTaskResult (#638) Apr 15, 2026

claude bot reviewed Apr 15, 2026

View reviewed changes

Comment thread src/mcp/server.ts Outdated

Comment thread src/mcp/server.ts

claude and others added 3 commits April 16, 2026 08:06

fix: ensure final statusMessage is set correctly during task result s…

9a234ab

…torage

jirispilka force-pushed the fix/task-final-status-message-638 branch from ad5d65e to 9a234ab Compare April 16, 2026 07:46

jirispilka and others added 5 commits April 16, 2026 09:59

test: add unit tests for task execution handling in ActorsMcpServer

9917447

fix: prevent updating task status to 'cancelled' if already terminal

35c643d

fix: update cancellation message to include tool prefix if available

e3d12aa

fix: update task status handling to correctly reflect 'failed' state

77c3bb6

This was referenced Apr 16, 2026

Skip task creation for pre-flight failures (payment, validation) #684

Open

Upstream: SDK requestStream() discards results for 'failed' tasks #685

Open

Upstream: mcpc pollTask() returns statusMessage instead of actual result #686

Open

jirispilka requested a review from Copilot April 16, 2026 11:33

Copilot started reviewing on behalf of jirispilka April 16, 2026 11:34 View session

Copilot AI reviewed Apr 16, 2026

View reviewed changes

Comment thread src/mcp/server.ts Outdated

Comment thread src/mcp/server.ts Outdated

Comment thread tests/unit/task.statusMessage.test.ts Outdated

Comment thread src/mcp/server.ts Outdated

jirispilka added 2 commits April 16, 2026 13:40

fix: enhance task result handling for x402 payment errors and improve…

ef827fa

… logging

fix: normalize cancellation messages and handle task result storage e…

5c87cfe

…rrors

jirispilka requested a review from Copilot April 16, 2026 11:53

Copilot started reviewing on behalf of jirispilka April 16, 2026 11:54 View session

Copilot AI reviewed Apr 16, 2026

View reviewed changes

Comment thread src/mcp/server.ts Outdated

Comment thread src/dev_server.ts

Comment thread src/mcp/server.ts

Comment thread src/mcp/server.ts

fix: improve task result storage with cancellation handling and error…

8805dec

… messaging

jirispilka requested a review from Copilot April 16, 2026 12:13

Copilot started reviewing on behalf of jirispilka April 16, 2026 12:14 View session

Copilot AI reviewed Apr 16, 2026

View reviewed changes

Comment thread src/mcp/utils.ts

Comment thread src/mcp/server.ts

Comment thread res/task_status_workaround.md

Comment thread tests/unit/task.statusMessage.test.ts Outdated

Comment thread tests/unit/server.task_execution.test.ts

Copilot started work on behalf of jirispilka April 16, 2026 12:21 View session

fix: apply follow-up review thread changes

558070b

Agent-Logs-Url: https://github.com/apify/apify-mcp-server/sessions/b6debe5d-50b7-4b92-9b85-8ab365c2df09 Co-authored-by: jirispilka <19406805+jirispilka@users.noreply.github.com>

Copilot finished work on behalf of jirispilka April 16, 2026 12:33

jirispilka added 2 commits April 16, 2026 14:43

fix: log non-cancellation storage failures and ensure task result han…

f8c119c

…dling continues

fix: handle task failure when storing results and update task status …

0b8d77e

…accordingly

jirispilka requested a review from Copilot April 16, 2026 15:53

Copilot started reviewing on behalf of jirispilka April 16, 2026 15:53 View session

Copilot AI reviewed Apr 16, 2026

View reviewed changes

This was referenced Apr 16, 2026

fix: Fill unit-test gaps for MCP task functionality #688

Merged

Client sees "Task <id> failed" instead of the real error/result on failed tasks modelcontextprotocol/typescript-sdk#1922

Open

-    log.setLevel(process.env.LOG_LEVEL === 'info' ? log.LEVELS.INFO : log.LEVELS.DEBUG);
+    const configuredLogLevel = (process.env.LOG_LEVEL ?? 'debug').trim().toUpperCase() as keyof typeof log.LEVELS;
+    const resolvedLogLevel = configuredLogLevel in log.LEVELS
+        ? log.LEVELS[configuredLogLevel]
+        : log.LEVELS.DEBUG;
+    log.setLevel(resolvedLogLevel);

Conversation

jirispilka commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Verified with mcpc

Follow up issues

Test plan

Uh oh!

Uh oh!

Uh oh!

jirispilka commented Apr 16, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jirispilka commented Apr 16, 2026

Uh oh!

Copilot AI commented Apr 16, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jirispilka commented Apr 15, 2026 •

edited

Loading