What causes "getting ready work: %w" in gastownhall/beads?

Inspect the wrapped cause for the actual GetReadyWork failure and address it (connection, corruption, timeout)

getting ready work: %w

Error message

getting ready work: %w

What it means

After collecting closed gates, findGateReadyMolecules calls GetReadyWork to learn which issue IDs are currently ready. A failure there is wrapped as 'getting ready work: %w', meaning the ready-work computation in the storage layer (dependency/status evaluation) errored.

Source

Thrown at cmd/bd/mol_ready_gated.go:150

	closedStatus := types.StatusClosed
	gateFilter := types.IssueFilter{
		IssueType: &gateType,
		Status:    &closedStatus,
	}

	closedGates, err := s.SearchIssues(ctx, "", gateFilter)
	if err != nil {
		return nil, fmt.Errorf("searching closed gates: %w", err)
	}

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

	// Step 2: Get ready work to check which steps are ready
	readyIssues, err := s.GetReadyWork(ctx, types.WorkFilter{})
	if err != nil {
		return nil, fmt.Errorf("getting ready work: %w", err)
	}
	readyIDs := make(map[string]bool)
	for _, issue := range readyIssues {
		readyIDs[issue.ID] = true
	}

	// Step 3: Get hooked molecules to filter out
	hookedStatus := types.StatusHooked
	hookedFilter := types.IssueFilter{
		Status: &hookedStatus,
	}
	hookedIssues, err := s.SearchIssues(ctx, "", hookedFilter)
	if err != nil {
		// Non-fatal: just continue without filtering
		hookedIssues = nil
	}
	// Batch-find parent molecules for hooked issues (bd-hn4q)
	hookedMolecules := make(map[string]bool)

View on GitHub (pinned to 71377f2769)

Solutions

Inspect the wrapped cause for the actual GetReadyWork failure and address it (connection, corruption, timeout)
Run bd doctor to validate database integrity
If proxied, restart or reconnect to the bd daemon and retry
Retry the command once storage is healthy

Example fix

// before
readyIssues, err := s.GetReadyWork(ctx, types.WorkFilter{})
if err != nil {
    return nil, fmt.Errorf("getting ready work: %w", err)
}
// after: fail fast with context for callers/agents
readyIssues, err := s.GetReadyWork(ctx, types.WorkFilter{})
if err != nil {
    return nil, fmt.Errorf("getting ready work for gate check: %w", err)
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check storage health before computing ready work
if err := s.SearchIssues(ctx, "", types.IssueFilter{Limit: ptr(1)}); err != nil {
    return fmt.Errorf("storage unavailable: %w", err)
}

Type guard

func storageOK(s molStore) bool { return s != nil }

Try / catch

ready, err := findGateReadyMolecules(ctx, s, gateType)
if err != nil {
    if strings.Contains(err.Error(), "getting ready work") {
        log.Printf("ready-work query failed: %v", errors.Unwrap(err))
    }
    return err
}

Prevention

Keep dependency graph clean; run bd doctor to detect corrupt deps
Avoid running concurrent writers against the same Dolt DB
Retry transient storage errors with backoff in automation

When it happens

Trigger: Running bd mol ready when GetReadyWork fails: database unavailable, dependency-graph query error, or proxied server returning an error for the ready-work endpoint.

Common situations: Corrupt dependency rows after interrupted sync; Dolt server down during proxied operation; large dependency graphs hitting query timeouts.

Related errors

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