What causes "resolving parent %q: %w" in gastownhall/beads?

Read the wrapped %w cause and address it (restart server, re-authenticate).

resolving parent %q: %w

Error message

resolving parent %q: %w

What it means

The generic counterpart to the not-found case: GetIssueOrWisp failed with an error other than storage.ErrNotFound while resolving the parent issue in the proxied-server label flow, and it is wrapped with %w preserving the cause (auth failure, server/storage error, etc.).

Source

Thrown at cmd/bd/label_proxied_server.go:157

	}
	if strings.HasPrefix(label, "provides:") {
		return HandleErrorRespectJSON("'provides:' labels are reserved for cross-project capabilities. Hint: use 'bd ship %s' instead", strings.TrimPrefix(label, "provides:"))
	}
	if uowProvider == nil {
		return HandleError("proxied-server UOW provider not initialized")
	}

	var (
		children []*types.Issue
		parentID string
	)
	err := uow.RunTx(ctx, uowProvider, func(ctx context.Context, uw uow.UnitOfWork) (string, error) {
		parent, _, rerr := workapi.GetIssueOrWisp(ctx, workapi.NewUOWDetailSource(uw), args[0])
		if errors.Is(rerr, storage.ErrNotFound) {
			return "", fmt.Errorf("resolving parent %q: not found", args[0])
		}
		if rerr != nil {
			return "", fmt.Errorf("resolving parent %q: %w", args[0], rerr)
		}
		parentID = parent.ID

		page, err := uw.IssueUseCase().SearchIssues(ctx, "", types.IssueFilter{ParentID: &parentID})
		if err != nil {
			return "", fmt.Errorf("searching children of %s: %w", parentID, err)
		}
		children = page.Items
		if len(children) == 0 {
			return "", nil
		}
		// THE ONE SURVIVING WISP SWITCH, and it is named rather than hidden.
		// This is the same four-way shape ga-26w10 deleted from `bd label` and
		// ga-2ltro.12 deleted from `bd tag`, `bd set-state` and the molecule
		// port — the branch a front door can get backwards and put a wisp's
		// label in the durable table. It survives because propagate is a search
		// plus a fan-out that must land as ONE transaction over N children, and
		// a per-child Lifecycle.Update is N transactions: the atomicity this

View on GitHub (pinned to 71377f2769)

Solutions

Read the wrapped %w cause and address it (restart server, re-authenticate).
Retry the command once the server is healthy.
Fall back to the non-proxied path if appropriate, after confirming the server config in bd is correct.

Defensive patterns

Strategy: retry

Validate before calling

# check server reachability before the command
bd doctor >/dev/null 2>&1 || { echo "bd server unhealthy" >&2; exit 1; }

Try / catch

out=$(bd label add "$PARENT_ID" "$LABEL" 2>&1) || {
  echo "$out" >&2   # wrapped %w shows the upstream cause
  sleep 2; bd label add "$PARENT_ID" "$LABEL"   # retry transient server faults
}

Prevention

Monitor server/daemon health before batch label operations.
Re-authenticate when wrapped errors indicate permission failures.
Retry only idempotent label operations; inspect %w first for permanent causes.

When it happens

Trigger: `bd label <sub> <parent-id> ...` through a proxied server where the GetIssueOrWisp call errors — server unreachable mid-call, permission/adapter failure, malformed response from the work API.

Common situations: Server-side outages or restarting daemon while issuing label commands; authentication/authorization problems against the proxied server; driver/storage faults on the server.

Related errors

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