What causes "failed to get issue: %v" in gastownhall/beads?

Address the embedded cause: restore backend connectivity or wait out the lock conflict.

failed to get issue: %v

Error message

failed to get issue: %v

What it means

Error from runSwarmStatusProxiedServer in cmd/bd/swarm_proxied_server.go:124. Raised when GetIssue on the resolved issue fails with a real (non not-found) error. The not-found gate already ran, so this is a genuine storage/use-case failure fetching the issue record; the cause is embedded with %v.

Source

Thrown at cmd/bd/swarm_proxied_server.go:124

	if uowProvider == nil {
		return HandleErrorRespectJSON("proxied-server UOW provider not initialized")
	}

	status, err := uow.RunTxRead(ctx, uowProvider, func(ctx context.Context, uw uow.UnitOfWork) (*SwarmStatus, error) {
		r := uowMolReader{uw: uw}

		issueID, err := utils.ResolvePartialID(ctx, r, args[0])
		if err != nil {
			return nil, fmt.Errorf("issue '%s' not found: %v", args[0], err)
		}

		issue, err := uw.IssueUseCase().GetIssue(ctx, issueID)
		if gateProxiedNotFound(err) || (err == nil && issue == nil) {
			return nil, fmt.Errorf("issue '%s' not found", issueID)
		}
		if err != nil {
			return nil, fmt.Errorf("failed to get issue: %v", err)
		}

		var epic *types.Issue

		if issue.IssueType == "molecule" && issue.MolType == types.MolTypeSwarm {
			deps, err := r.GetDependencyRecords(ctx, issue.ID)
			if err != nil {
				return nil, fmt.Errorf("failed to get swarm dependencies: %v", err)
			}
			for _, dep := range deps {
				if dep.Type == types.DepRelatesTo {
					epic, err = uw.IssueUseCase().GetIssue(ctx, dep.DependsOnID)
					if err != nil {
						return nil, fmt.Errorf("failed to get linked epic: %v", err)
					}
					break
				}
			}

View on GitHub (pinned to 71377f2769)

Solutions

Address the embedded cause: restore backend connectivity or wait out the lock conflict.
Retry the command after transient backend issues clear.
Run `bd doctor` to verify proxied-server and database configuration.
Restart the proxied-server / Dolt process if the failure persists.

Defensive patterns

Strategy: retry

Validate before calling

bd doctor || echo "fix storage/backend before bd swarm status"

Try / catch

if err != nil && strings.Contains(err.Error(), "failed to get issue") {
    // inspect cause, check backend, back off and retry
}

Prevention

Keep the Dolt backend reachable and not overloaded
Avoid concurrent writers during swarm status reads
Run bd doctor when proxied-server errors recur

When it happens

Trigger: `bd swarm status <id>` in proxied-server mode when uw.IssueUseCase().GetIssue returns a non-not-found error — transaction failure, driver error, or backend unavailability.

Common situations: Dolt backend connection dropped mid-command; read-transaction lock conflict with a concurrent writer; proxied-server misconfiguration or timeout under load.

Related errors

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