API returns misleading success when completing non-existent taskId

[evalor]

Description

When attempting to complete a task with a non-existent taskId, the API returns a success response even though no task was actually completed. This misleading behavior can cause users to believe their operation succeeded when it actually had no effect.

Steps to Reproduce

1. Call the complete_task tool with a non-existent taskId
2. Observe that the API returns a success response
3. Verify that no task status was actually changed

Expected Behavior

The API should return an error response indicating that:

• The specified task does not exist
• No operation was performed
• The user should verify the task ID

Actual Behavior

• The API returns a success response (HTTP 200)
• No error message or warning is provided
• The user receives false confirmation that the task was completed
• In reality, no task status was changed

Impact

• User Confusion: Users believe their action was successful when it wasn't
• Data Integrity: Users may lose track of actual task status
• Debugging Difficulty: Silent failures make it hard to identify issues
• Workflow Disruption: Automated workflows may proceed incorrectly based on false success responses

Suggested Fix

1. Validate taskId: Before performing operations, verify that the task exists
2. Return appropriate error: If task doesn't exist, return HTTP 404 with clear error message
3. Consistent behavior: Apply same validation to all task operations (update, delete, complete)

Environment

• MCP Server Version: Dida365 MCP Server
• Test Date: 2025-11-26

---

Related Test Case

Test Scenario Details

Test ID: E-4
Category: Error Handling - Business Logic
Test Request: Complete a task that does not exist

Test Steps

1. User request: "Complete a task that doesn't exist"
2. MCP tool called: complete_task
   - projectId: "inbox" (or any valid project)
   - taskId: "non_existent_task_id_99999"
3. API Response: Success (HTTP 200)
4. Actual result: No task was completed

Expected vs Actual Results

Aspect	Expected	Actual
Response Code	404 Not Found	200 OK
Error Message	"Task not found"	None
Task Status	N/A (doesn't exist)	Unchanged
User Feedback	Clear error	False success

Test Verification

1. Query all tasks before operation
2. Attempt to complete non-existent task
3. Receive success response (BUG)
4. Query all tasks after operation
5. Confirm no task status changed

Related Test Scenarios

Test ID	Scenario	Status	Relationship
E-3	Invalid projectId handling	⚠️ Issue Found	Similar pattern - silent failure
E-4	Non-existent taskId handling	⚠️ This Issue	Current issue
Batch Delete	Inbox task deletion	⚠️ Issue Found	API returns success but tasks remain

Additional Context

This issue is part of a broader pattern observed during comprehensive MCP server testing on 2025-11-26. Multiple API endpoints exhibit similar "silent success" behavior when operating on non-existent resources:

1. E-3: Creating tasks with invalid projectId silently redirects to Inbox
2. E-4: Completing non-existent tasks returns success (this issue)
3. Batch Delete: Deleting Inbox tasks returns success but tasks persist

This indicates that the API layer may implement idempotency for REST interfaces. Implementing consistent validation and error handling would significantly improve the reliability and user experience of the MCP server.

[evalor]

@Copilot View this issue

This may be the same problem. Due to the design of RESTful, the interface is required to always return consistent results. Semantically, the non-existent task of Delete should also be successful, because the task does not exist after operation, which is the right behavior. We should provide the "strict mode" parameter. When MCP runs in strict mode, it will check whether the task exists before deletion, which also affects other interfaces with the same design.