What causes "parent issue '%s' not found" in gastownhall/beads?

Run `bd show ` to confirm the issue exists in this database

parent issue '%s' not found

Error message

parent issue '%s' not found

What it means

getHierarchicalChildren resolves the requested --parent issue before enumerating its descendants. When the storage layer reports that no issue exists for the given parentID (parentIssue == nil), the function refuses to silently return an empty list and throws this error so the user knows the parent itself is invalid.

Source

Thrown at cmd/bd/list_show_filter_modes.go:61

// 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
	}

	// Include the parent as the tree root only when descendants exist,
	// so the tree renderer can draw the hierarchy with the parent at the top.

View on GitHub (pinned to 71377f2769)

Solutions

Run `bd show <parentID>` to confirm the issue exists in this database
Check for typos or prefix mistakes in the parent ID
Sync the database (`bd dolt pull`) if the parent was created elsewhere
Re-run the command from the correct repository / -C directory

Example fix

// before
bd list --parent bd-9999
// after
bd show bd-9999   # verify it exists first
bd list --parent bd-9999

Defensive patterns

Strategy: validation

Validate before calling

if out, err := exec.Command("bd", "show", parentID).Run(); err != nil {
    return fmt.Errorf("parent %s does not exist; aborting", parentID)
}

Prevention

Always `bd show <id>` before using an ID as a parent filter
Pull (`bd dolt pull`) before scripting against remotely-created issues
Run commands from the correct repo/beads dir

When it happens

Trigger: Calling `bd list --parent <id>` (or the watched-issues path via loadWatchedIssues) with an issue ID that does not exist in the store, e.g. after the issue was deleted, the ID was mistyped, or the local Dolt database has not been synced and is missing that issue.

Common situations: Typo in parent ID; referencing an issue deleted by a teammate before your local `bd dolt pull`; running in the wrong repo/beads dir so the parent lives in a different database; stale scripts holding old IDs.

Related errors

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