TaskUpdate silently fails when called with wrong parameter name (id vs taskId)

Resolved 💬 1 comment Opened Apr 11, 2026 by CK-IP Closed May 24, 2026

Description

When TaskUpdate is called with an incorrect parameter name (id instead of taskId), the InputValidationError is returned in the tool result but the model does not recognize it as a failure and continues as if the update succeeded. Task statuses silently remain stale.

Steps to reproduce

  1. Create tasks with TaskCreate during a multi-step workflow
  2. After context compaction (session summary), call TaskUpdate with the wrong parameter name:
TaskUpdate({ "id": 3, "status": "completed" })
  1. The tool returns:
InputValidationError: TaskUpdate failed — The required parameter taskId is missing. An unexpected parameter id was provided.
  1. The model does not retry or surface the error to the user — it continues as if the task was updated

Expected behavior

Either:

  • The model recognizes the InputValidationError as a failed tool call and retries with the correct parameter, or
  • The error is surfaced visibly in the UI so the user is aware tasks weren't updated

Actual behavior

The validation error is returned but effectively swallowed. The model proceeds without retrying. Tasks remain in their previous state ("in_progress" / "pending") even though the underlying work completed. The status bar continues to show stale mid-workflow state.

Impact

  • Task list shows incorrect state — completed work appears as "in_progress" or "pending"
  • Status bar is misleading — displays stale progress after work is done
  • User confusion — users see contradictory signals (completed output vs stale task list)

This is more likely to occur after context compaction, where the model loses the exact parameter schema from earlier in the conversation and guesses parameter names.

Environment

  • Claude Code, Sonnet 4.6
  • Long-running session with mid-session context compaction
  • macOS (Darwin 24.0.0)

Suggested fix

  1. Model-level: Treat InputValidationError tool results the same as other tool errors — trigger a retry with corrected parameters
  2. UI-level: Surface tool validation errors as visible warnings in the conversation
  3. Optional: Accept id as an alias for taskId since it's a natural/common parameter name the model gravitates toward

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗