What causes "failed to get dependents of %s: %w" in gastownhall/beads?

Inspect the wrapped error via errors.Unwrap to identify the storage-level cause and address it.

failed to get dependents of %s: %w

Error message

failed to get dependents of %s: %w

What it means

loadDescendants collects the children of a parent issue within a template. It calls s.GetDependentsWithMetadata(parentID) and, if that storage call fails, throws 'failed to get dependents of %s: %w' wrapping the cause. Only DepParentChild relationships are kept afterwards, so the error is purely about reading dependents, not about relationship filtering.

Source

Thrown at cmd/bd/template.go:140

	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).
// Without this, cyclic parent-child dependencies cause unbounded recursion leading to OOM.
func loadDescendants(ctx context.Context, s molReader, subgraph *TemplateSubgraph, parentID string, visited map[string]bool) error {
	// Track children we've already added to avoid duplicates
	addedChildren := make(map[string]bool)

	// Strategy 1: Get direct parent-child dependents with relationship metadata.
	dependents, err := s.GetDependentsWithMetadata(ctx, parentID)
	if err != nil {
		return fmt.Errorf("failed to get dependents of %s: %w", parentID, err)
	}

	// Only keep explicit parent-child relationships.
	for _, dependent := range dependents {
		if dependent.DependencyType != types.DepParentChild {
			continue
		}

		if _, exists := subgraph.IssueMap[dependent.ID]; exists {
			continue // Already in subgraph
		}

		// Cycle detection (GH#2719)
		if visited[dependent.ID] {
			continue
		}

		child := dependent.Issue

View on GitHub (pinned to 71377f2769)

Solutions

Inspect the wrapped error via errors.Unwrap to identify the storage-level cause and address it.
Run `bd doctor` to check and repair database integrity.
Retry the operation after any transient driver failure.
Re-sync from remote (bd dolt pull) if local dependency data is inconsistent.

Defensive patterns

Strategy: retry

Try / catch

dependents, err := s.GetDependentsWithMetadata(ctx, parentID)
if err != nil {
	return fmt.Errorf("failed to get dependents of %s: %w", parentID, err)
}

Prevention

Run `bd doctor` after interrupted commands to catch inconsistent dependency data.
Avoid killing `bd` mid-operation.
Re-sync from remote if local data looks inconsistent.

When it happens

Trigger: GetDependentsWithMetadata failing for the parent issue while loading a template subgraph (recursively via loadTemplateSubgraph or deeper via loadDescendants): storage read error, transaction failure, or driver error.

Common situations: Corrupt dependency index in the Dolt database; interrupted prior `bd` command leaving inconsistent data; concurrent writes conflicting with the read.

Related errors

AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/e83d157073ffdd1b. Report an issue: GitHub.