eyaltoledano/claude-task-master · warning

Warning: ${result.failedCount} tasks failed to import: ${fai

Error message

Warning: ${result.failedCount} tasks failed to import: ${failedTasks}

What it means

During export, export.service.ts performExport() sends tasks to an external target (a brief). If some tasks fail on the remote side, it logs a warning listing each failed external ID with its error, while still reporting the successful count separately.

Source

Thrown at packages/tm-core/src/modules/integration/services/export.service.ts:715

				},
				body: JSON.stringify(requestBody)
			});

			if (!response.ok) {
				const errorText = await response.text();
				throw new Error(
					`API request failed: ${response.status} - ${errorText}`
				);
			}

			const result = (await response.json()) as BulkTasksResponse;

			if (result.failedCount > 0) {
				const failedTasks = result.results
					.filter((r) => !r.success)
					.map((r) => `${r.externalId}: ${r.error}`)
					.join(', ');
				console.warn(
					`Warning: ${result.failedCount} tasks failed to import: ${failedTasks}`
				);
			}

			console.log(
				`Successfully exported ${result.successCount} of ${result.totalTasks} tasks to brief ${briefId}`
			);
		} else {
			// Direct Supabase approach is no longer supported
			// The extractTasks method has been removed from SupabaseRepository
			// as we now exclusively use the API endpoint for exports
			throw new Error(
				'Export API endpoint not configured. Please set TM_PUBLIC_BASE_DOMAIN environment variable to enable task export.'
			);
		}
	}

	/**

View on GitHub (pinned to c0c98d367c)

Solutions

  1. Read the failedTasks list in the warning to see each external ID and its specific error
  2. Fix the underlying data for failed tasks (missing fields, invalid references) and re-run the export
  3. Retry the export if failures were transient (network/rate-limit)
  4. Check API quotas/permissions on the target brief if many tasks fail consistently

Example fix

// before
await exportService.exportTasks(tasks, { briefId }); // ignores partial failures
// after
const result = await exportService.exportTasks(tasks, { briefId });
const failed = result.results.filter(r => !r.success);
if (failed.length) console.error('Retry failed IDs:', failed.map(f => f.externalId));
Defensive patterns

Strategy: retry

Validate before calling

const invalid = tasks.filter(t => !t.title || !t.id);
if (invalid.length) throw new Error(`Fix before export: ${invalid.map(t => t.id).join(', ')}`);

Try / catch

const result = await exportService.exportTasks(tasks, { briefId });
const failed = result.results.filter(r => !r.success);
for (const f of failed) console.error(`${f.externalId}: ${f.error}`);
if (failed.length && isTransient(failed)) await exportService.exportTasks(failed.map(f => f.task), { briefId });

Prevention

When it happens

Trigger: exportTasks() completes with result.failedCount > 0 — individual task pushes to the brief failed (rejected by the API, validation errors, duplicate/missing external IDs) even though the overall export didn't throw.

Common situations: Remote API rejects tasks missing required fields, network blips during batch upload, tasks referencing entities that don't exist on the target, rate limiting on large exports.

Related errors


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