Bug: get_inbox_tasks returns "Not Found: Resource not found: Resource"

View original issue on GitHub  ·  Variant 3

get_inbox_tasks Fails with "Resource Not Found"

The get_inbox_tasks function in the @alexarevalo9/ticktick-mcp-server package is consistently failing with a "Not Found: Resource not found: Resource" error. This occurs despite successful connections to the TickTick API and the proper functioning of other API calls like get_user_projects and get_project_with_data. This issue impacts users who rely on the dedicated get_inbox_tasks function to retrieve tasks specifically assigned to their TickTick Inbox.

Root Cause Analysis

The underlying problem likely lies in the way get_inbox_tasks determines the Inbox's project ID. TickTick's API design uses project IDs to identify various task lists, including the Inbox. The get_inbox_tasks function probably attempts to dynamically retrieve the Inbox's project ID from a user profile endpoint. The error suggests that either the expected field (potentially named inboxId or similar) is missing from the user profile data, or the structure of that data has changed, causing the function to fail in resolving the correct project ID. This could be due to variations in user account configurations, API changes on the TickTick side, or an oversight in handling different account types within the @alexarevalo9/ticktick-mcp-server package.

Solution and Implementation

A robust solution involves a multi-pronged approach, prioritizing reliability and adaptability:

  1. Implement a Fallback Mechanism: If the attempt to retrieve the Inbox ID from the user profile fails, the function should default to using the well-known "inbox" ID. This ID seems to consistently represent the Inbox across different TickTick accounts, as evidenced by the successful workaround using get_project_with_data({ projectId: "inbox" }).
  2. Enhance Error Handling: Improve the error handling to provide more informative error messages. Instead of a generic "Resource Not Found," the error message should indicate that the Inbox ID could not be resolved from the user profile, guiding users and developers toward the root cause.
  3. Implement Caching: Cache the Inbox ID after successfully retrieving it from the user profile. This reduces the number of API calls required and improves performance. However, implement a cache invalidation strategy (e.g., after a certain time period) to handle potential changes in the user profile data.

Here's an example of how to implement the fallback mechanism in code (JavaScript):


async function getInboxTasks() {
  let inboxProjectId;

  try {
    // Attempt to retrieve Inbox ID from user profile (replace with actual API call)
    const userProfile = await fetchUserProfile();
    inboxProjectId = userProfile.inboxId; // Assuming 'inboxId' is the field name
  } catch (error) {
    console.warn("Failed to retrieve Inbox ID from user profile:", error);
    inboxProjectId = "inbox"; // Fallback to default Inbox ID
  }

  if (!inboxProjectId) {
    inboxProjectId = "inbox"; // Ensure a value is always set
  }

  // Now use inboxProjectId to fetch the tasks
  const tasks = await getProjectWithData({ projectId: inboxProjectId });
  return tasks;
}

The fetchUserProfile() function represents the actual API call to retrieve the user profile data. The getProjectWithData() function is assumed to already exist and correctly fetch tasks for a given project ID.

Related Considerations and Best Practices

By implementing these solutions and following best practices, the @alexarevalo9/ticktick-mcp-server package can reliably retrieve Inbox tasks and provide a seamless user experience.