eyaltoledano/claude-task-master · warning

Failed to get tasks for brief ${brief.id}:

Error message

Failed to get tasks for brief ${brief.id}:

What it means

BriefService.getTagsWithStats enriches each brief with task counts. If fetching tasks for a brief throws, the service catches the error, logs this warning, and returns the brief with 0 tasks instead of failing the whole call. This message is that diagnostic log, not a thrown exception.

Source

Thrown at packages/tm-core/src/modules/briefs/services/brief-service.ts:146

						name:
							brief.document?.title ||
							brief.document?.document_name ||
							brief.id,
						isCurrent: currentBriefId === brief.id,
						taskCount: tasks.length,
						completedTasks,
						statusBreakdown,
						subtaskCounts:
							subtaskCounts.totalSubtasks > 0 ? subtaskCounts : undefined,
						created: brief.createdAt,
						description: brief.document?.description,
						status: brief.status,
						briefId: brief.id,
						updatedAt: brief.updatedAt
					};
				} catch (error) {
					// If we can't get tasks for a brief, return it with 0 tasks
					console.warn(`Failed to get tasks for brief ${brief.id}:`, error);
					return {
						name:
							brief.document?.title ||
							brief.document?.document_name ||
							brief.id,
						isCurrent: currentBriefId === brief.id,
						taskCount: 0,
						completedTasks: 0,
						statusBreakdown: {},
						created: brief.createdAt,
						description: brief.document?.description,
						status: brief.status,
						briefId: brief.id,
						updatedAt: brief.updatedAt
					};
				}
			})
		);

View on GitHub (pinned to c0c98d367c)

Solutions

  1. Check that tasks for brief.id actually exist and are readable via the tasks service/API
  2. Re-run getTagsWithStats if the cause was a transient network error
  3. Verify brief.id references are not dangling after brief deletion/merge
  4. Fix auth/permissions if the tasks fetch fails with 401/403
Defensive patterns

Strategy: fallback

Validate before calling

// verify brief and its tasks are reachable before computing stats
const briefTasks = await tmCore.tasks.list({ briefId: brief.id }).catch(() => null);
if (briefTasks === null) console.warn(`Brief ${brief.id} tasks unavailable; stats will show 0`);

Type guard

function hasFetchableTasks(result) {
  return result !== null && Array.isArray(result.tasks);
}

Try / catch

try {
  const tags = await briefService.getTagsWithStats();
  for (const t of tags) {
    if (t.taskCount === 0) console.warn(`Brief ${t.name} reported 0 tasks — may be a fetch failure`);
  }
} catch (error) { /* handles only total failure */ }

Prevention

When it happens

Trigger: Calling getTagsWithStats when the underlying tasks lookup for a specific brief.id fails — brief referencing a nonexistent/renamed task set, network failure to the task backend, or permission denial on the brief's task data.

Common situations: Deleted briefs with dangling task links; brief IDs changed after an import; intermittent API failures producing misleading taskCount: 0 stats.

Related errors


AI-assisted analysis of eyaltoledano/claude-task-master@c0c98d367c (2026-08-29). Data as JSON: /api/errors/4bbc1a1375e9b4e3. Report an issue: GitHub.