gastownhall/beads · error
querying blocked issues: %w
Error message
querying blocked issues: %w
What it means
findStaleMolecules aggregates stale molecules and needs the set of currently blocked issues to compute what each stale molecule blocks. When the underlying storage query GetBlockedIssues fails (backend/driver error, context cancellation, store not initialized), the error is wrapped with %w and propagated to runMolStale, aborting the command.
Source
Thrown at cmd/bd/mol_stale.go:142
fmt.Printf("Total: %d stale", result.TotalCount)
if result.BlockingCount > 0 {
fmt.Printf(", %d blocking other work", result.BlockingCount)
}
fmt.Println()
}
// findStaleMolecules queries the database for stale molecules
func findStaleMolecules(ctx context.Context, s molReader, blockingOnly, unassignedOnly, showAll bool) (*StaleResult, error) {
// Get all epics eligible for closure (complete but unclosed)
epicStatuses, err := s.GetEpicsEligibleForClosure(ctx)
if err != nil {
return nil, fmt.Errorf("querying epics: %w", err)
}
// Get blocked issues to find what each stale molecule is blocking
blockedIssues, err := s.GetBlockedIssues(ctx, types.WorkFilter{})
if err != nil {
return nil, fmt.Errorf("querying blocked issues: %w", err)
}
// Build map of issue ID -> what issues it's blocking
blockingMap := buildBlockingMap(blockedIssues)
var staleMolecules []*StaleMolecule
blockingCount := 0
for _, es := range epicStatuses {
// Skip if not eligible for close (not all children closed)
if !es.EligibleForClose {
continue
}
// Skip if no children and not showing all
if es.TotalChildren == 0 && !showAll {
continue
}View on GitHub (pinned to 71377f2769)
Solutions
- Check database availability and re-run `bd mol stale` (verify with `bd doctor` or a simple `bd list`).
- Inspect the wrapped cause (%w) printed after 'querying blocked issues:' for the driver-level error and fix that first.
- If running in proxied-server mode, restart the server process to re-establish the store connection.
- Re-sync the database (`bd dolt pull`) if corruption or stale refs are suspected.
Defensive patterns
Strategy: try-catch
Validate before calling
// Go: check store health before invoking the command
if err := store.HealthCheck(ctx); err != nil {
return fmt.Errorf("database unavailable, fix storage before `bd mol stale`: %w", err)
} Try / catch
if _, err := runMolStale(cmd, args); err != nil {
if strings.Contains(err.Error(), "querying blocked issues") {
// inspect wrapped cause, check DB connectivity, retry once
}
return err
} Prevention
- Keep the local Dolt/store process running and reachable before running mol commands
- Run `bd doctor` to catch storage problems early
- Avoid killing the process mid-query (signals produce context cancellation)
- Periodically `bd dolt pull` to keep the database consistent
When it happens
Trigger: Calling `bd mol stale` (directly or via runMolStaleProxiedServer) when the underlying store's GetBlockedIssues(ctx, types.WorkFilter{}) call fails — e.g. database unavailable/corrupt, driver error, or context canceled mid-query.
Common situations: Running mol stale against a Dolt database that is offline or unreachable; a partially synced or corrupted database; running the command in proxied-server mode where the backing store connection dropped; Ctrl-C during the query.
Related errors
- querying epics: %w
- reparent: list current parent: %w
- failed to get epics: %w
- failed to batch-fetch child statuses from %s: %w
- failed to batch-fetch epic issues: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/26850cba5c02447e.
Report an issue: GitHub.