gastownhall/beads · error
failed to get dependencies for %s: %w
Error message
failed to get dependencies for %s: %w
What it means
After loading the template root, loadTemplateSubgraph iterates every issue in the subgraph and calls s.GetDependencyRecords to collect dependencies. If the storage layer fails to read dependency records for any issue, the operation aborts with 'failed to get dependencies for %s: %w' wrapping the underlying error. This is a storage-read failure, not a data-shape problem — dependencies that fall outside the subgraph are simply filtered, not errors.
Source
Thrown at cmd/bd/template.go:113
}
subgraph := &TemplateSubgraph{
Root: root,
Issues: []*types.Issue{root},
IssueMap: map[string]*types.Issue{root.ID: root},
}
// Recursively load all children (with cycle detection, GH#2719)
visited := map[string]bool{root.ID: true}
if err := loadDescendants(ctx, s, subgraph, root.ID, visited); err != nil {
return nil, err
}
// Load all dependencies within the subgraph
for _, issue := range subgraph.Issues {
deps, err := s.GetDependencyRecords(ctx, issue.ID)
if err != nil {
return nil, fmt.Errorf("failed to get dependencies for %s: %w", issue.ID, err)
}
for _, dep := range deps {
// Only include dependencies where both ends are in the subgraph
if _, ok := subgraph.IssueMap[dep.DependsOnID]; ok {
subgraph.Dependencies = append(subgraph.Dependencies, dep)
}
}
}
return subgraph, nil
}
// loadDescendants recursively loads all child issues.
// It uses two strategies to find children:
// 1. Check dependency records for parent-child relationships
// 2. Check for hierarchical IDs (parent.N) to catch children with missing/wrong deps
//
// The visited set tracks IDs already expanded to detect cycles (GH#2719).View on GitHub (pinned to 71377f2769)
Solutions
- Read the wrapped cause (%w) — fix the underlying storage error it reports first.
- Run `bd doctor` to diagnose database health and repair common corruption issues.
- Retry the command; transient driver/transaction failures often clear on retry.
- Back up and re-sync the database (bd dolt pull) if dependency data is corrupt.
Example fix
// before (storage layer error)
deps, err := s.GetDependencyRecords(ctx, issue.ID)
// caller fix: inspect wrapped error
fmt.Printf("%+v\n", errors.Unwrap(err)) Defensive patterns
Strategy: retry
Try / catch
deps, err := s.GetDependencyRecords(ctx, issue.ID)
if err != nil {
return fmt.Errorf("failed to get dependencies for %s: %w", issue.ID, err)
}
// at caller: retry once on transient storage errors after unwrapping cause Prevention
- Keep the Dolt database healthy with periodic `bd doctor` runs.
- Avoid concurrent `bd` writes during template operations.
- Monitor disk space in repos with large templates.
When it happens
Trigger: GetDependencyRecords returning an error for any issue in the template subgraph: database corruption of dependency tables, a closed/failed transaction, driver-level I/O failure, or Dolt connection errors mid-operation.
Common situations: Corrupt or partially-migrated .beads Dolt database; disk full during a large clone; concurrent `bd` processes causing transaction conflicts; embedded Dolt driver failures.
Related errors
- failed to remove relates-to %s -> %s: %w
- add deps: classify sources: %w
- delete: drop deps: %w
- delete: drop wisp deps: %w
- delete: drop sync-plane edges into deleted wisps: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/a238424b5bd08c10.
Report an issue: GitHub.