gastownhall/beads · error
batch create: %w
Error message
batch create: %w
What it means
Inside the apply transaction, `tx.CreateIssues` bulk-inserts all plan nodes' issues. Any storage/DB failure is wrapped as `batch create: ...`, and because it happens in a transaction the entire graph apply is rolled back — no partial nodes are left behind.
Source
Thrown at cmd/bd/graph_apply.go:965
for i, node := range plan.Nodes {
issue, err := graphApplyNodeIssue(node, opts, actor, owner)
if err != nil {
return err
}
if node.Assignee != "" {
if node.AssignAfterCreate {
pendingAssignees[i] = node.Assignee
} else {
issue.Assignee = node.Assignee
}
}
issues = append(issues, issue)
}
if err := tx.CreateIssues(ctx, issues, actor); err != nil {
return fmt.Errorf("batch create: %w", err)
}
for i, node := range plan.Nodes {
keyToID[node.Key] = issues[i].ID
}
// Resolve MetadataRefs now that all IDs are known.
for i, node := range plan.Nodes {
if len(node.MetadataRefs) == 0 {
continue
}
metaJSON, err := types.MergeMetadataRefs(issues[i].Metadata, node.MetadataRefs, keyToID)
if err != nil {
return fmt.Errorf("node %q: %w", node.Key, err)
}
updates := map[string]interface{}{
"metadata": metaJSON,
}View on GitHub (pinned to 71377f2769)
Solutions
- Inspect the wrapped inner error to identify the driver-level cause.
- Verify the storage backend (Dolt) is running and reachable.
- Check for duplicate/conflicting issue keys already present in the database.
- Re-run the apply after fixing storage conditions; the transactional rollback means retry is safe.
Defensive patterns
Strategy: retry
Validate before calling
if err := bd Doctor/health check; storage unreachable, abort before apply:
if !storageReachable(doltAddr) { return errors.New("storage backend unavailable; aborting graph apply") } Try / catch
err := bd.GraphApply(ctx, plan)
if err != nil && strings.HasPrefix(err.Error(), "batch create:") {
// transaction rolled back; safe to retry after checking backend health
return retryWithBackoff(func() error { _, err := bd.GraphApply(ctx, plan); return err }, 3)
} Prevention
- Verify Dolt/server health before large applies.
- Ensure the plan has no keys colliding with existing issues.
- Monitor disk space on the storage host.
- Rely on transactional rollback — retries are safe.
When it happens
Trigger: Any underlying driver/Dolt error during batch insert: constraint violations, storage backend unavailable, invalid field values that pass client validation but fail at the driver, or I/O errors.
Common situations: Dolt server down or unreachable mid-apply; duplicate issue keys colliding with existing data; corrupted local Dolt database; disk full.
Related errors
- node %q: updating metadata refs: %w
- graph create: %w
- line %d (%s): %w
- resolving ID %s: %w
- failed to check parent issue: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/7655ad7761bc276b.
Report an issue: GitHub.