What causes "error checking parent issue: %v" in gastownhall/beads?

Verify the parent ID is correct and the issue exists (`bd show `)

error checking parent issue: %v

Error message

error checking parent issue: %v

What it means

getHierarchicalChildren verifies the requested parent issue exists before walking descendants; this wraps the storage GetIssue failure for that parent. Note it uses %v (not %w), so the wrapped error is not machine-unwrappable. A successful fetch returning nil leads to the separate 'parent issue not found' error.

Source

Thrown at cmd/bd/list_show_filter_modes.go:58

// above are what is left over — so this file is now the exception's whole
// remaining reason rather than one of several. It did not leave the config's
// exception list with this commit, and the count in issueops/reader.go's claim
// is unchanged for that reason: three modes here still name the type.
//
// Widening the hole is an edit in the config and a diff a reviewer sees.

// getHierarchicalChildren handles the --tree --parent combination logic.
// baseFilter carries CLI filters (--type, --status, etc.) through the recursive walk.
func getHierarchicalChildren(ctx context.Context, store storage.DoltStorage, dbPath string, parentID string, baseFilter types.IssueFilter) ([]*types.Issue, error) {
	// First verify that the parent issue exists
	var parentIssue *types.Issue
	err := withStorage(ctx, store, dbPath, func(s storage.DoltStorage) error {
		var err error
		parentIssue, err = s.GetIssue(ctx, parentID)
		return err
	})
	if err != nil {
		return nil, fmt.Errorf("error checking parent issue: %v", err)
	}
	if parentIssue == nil {
		return nil, fmt.Errorf("parent issue '%s' not found", parentID)
	}

	// Use recursive search to find all descendants using the same logic as --parent filter.
	// The parent itself is NOT included in the result set — only actual children and
	// their descendants. This matches the behavior of --json and --flat (GH#3349).
	allDescendants := make(map[string]*types.Issue)

	err = findAllDescendants(ctx, store, dbPath, parentID, baseFilter, allDescendants)
	if err != nil {
		return nil, fmt.Errorf("error finding descendants: %v", err)
	}

	if len(allDescendants) == 0 {
		return nil, nil
	}

View on GitHub (pinned to 71377f2769)

Solutions

Verify the parent ID is correct and the issue exists (`bd show <id>`)
Run `bd doctor` to check database health
Run from the repository root so .beads/ dbPath resolves
If the DB is corrupt, restore from .beads/issues.jsonl export or backup

Defensive patterns

Strategy: validation

Validate before calling

# Verify the parent exists and DB is reachable before hierarchical list
bd show "$parent" >/dev/null 2>&1 || { echo "parent $parent missing or DB unreachable"; exit 1; }

Try / catch

// Distinguish missing parent vs storage failure
out=$(bd list --parent "$parent" 2>&1) || case "$out" in
  *"not found"*) exit 2;;  # bad ID
  *"error checking parent"*) bd doctor; exit 1;;  # storage problem
esac

Prevention

Validate parent IDs with `bd show` before --parent lists
Run bd from the repo root so .beads is found
Monitor DB health with `bd doctor`; keep exports/backups for corruption recovery

When it happens

Trigger: `bd list --parent <id>` (hierarchical mode) where the storage GetIssue call for parentID errors — DB open failure, corruption, or storage-layer exception in withStorage.

Common situations: Corrupt or missing Dolt database file, wrong dbPath / running outside the repo (.beads dir missing), storage locked by another process, or a transient embedded-store error.

Related errors

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