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
- Read the failedTasks list in the warning to see each external ID and its specific error
- Fix the underlying data for failed tasks (missing fields, invalid references) and re-run the export
- Retry the export if failures were transient (network/rate-limit)
- 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
- Validate task data against the target API schema before exporting
- Batch large exports to avoid rate limiting
- Log and monitor failedCount on every export
- Keep retry logic for transient network failures
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
- API request failed: ${response.status} - ${errorText}
- EXPORT_FAILED
- API_ERROR
- AUTHENTICATION_ERROR
- MISSING_CONFIGURATION
AI-assisted analysis of eyaltoledano/claude-task-master@c0c98d367c (2026-08-29).
Data as JSON: /api/errors/29fde97da70ce2e5.
Report an issue: GitHub.