gastownhall/beads · error
failed to search issues: %w
Error message
failed to search issues: %w
What it means
ResolvePartialID resolves a partial or fully-qualified issue ID against the storage backend. After the exact-ID lookup fails, it falls back to a substring search via store.SearchIssueIDs; if that underlying storage call returns an error, it is wrapped with this message. This is a transport/storage failure, not a problem with the input ID itself — the original store error is preserved via %w.
Source
Thrown at internal/utils/id_parser.go:139
// If exact match failed, try substring search.
// Use the hash part as a search query to leverage SQL-level filtering
// (id LIKE %hash%) instead of loading ALL issues into memory.
// On large databases (23k+ issues over MySQL wire protocol), loading all
// issues took 60+ seconds; with SQL filtering it's near-instant.
hashPart := strings.TrimPrefix(normalizedID, prefixWithHyphen)
searchPart, ok := partialIDSearchPart(hashPart)
if !ok {
return "", fmt.Errorf("no issue found matching %q", input)
}
// Narrow projection: this loop only reads the .ID field, so use the
// SearchIssueIDs path instead of SearchIssues. Avoids hydrating all
// 45+ issue columns (including big TEXT fields like description, design,
// notes, metadata, payload) only to discard them.
filter := types.IssueFilter{}
ids, err := store.SearchIssueIDs(ctx, searchPart, filter)
if err != nil {
return "", fmt.Errorf("failed to search issues: %w", err)
}
var matches []string
var exactMatch string
for _, id := range ids {
// Check for exact full ID match first (case: user typed full ID with different prefix)
if id == input {
exactMatch = id
break
}
// Extract hash from each issue using config-aware prefix extraction.
// This correctly handles multi-hyphen prefixes (e.g., "hacker-news-ko4"
// yields hash "ko4", not "news-ko4" from naive first-hyphen split).
var issueHash string
if p := ExtractIssuePrefixKnown(id, knownPrefixes); p != "" && strings.HasPrefix(id, p+"-") {
issueHash = id[len(p)+1:]View on GitHub (pinned to 71377f2769)
Solutions
- Inspect the wrapped cause with errors.Unwrap or %v on the returned error to see the real storage failure
- Verify the storage backend is running and reachable (bd doctor, check the Dolt server / database file)
- Re-run with a fresh or longer context deadline; large DBs can exceed short timeouts
- If it appeared after an upgrade, check for schema migration steps and run them
- Retry once connectivity is restored — this error is transient when caused by network/backend outages
Example fix
// before
id, err := utils.ResolvePartialID(ctx, store, "a3f8", cfg)
if err != nil { log.Fatal(err) } // hides the real storage cause
// after
id, err := utils.ResolvePartialID(ctx, store, "a3f8", cfg)
if err != nil {
if errors.Unwrap(err) != nil {
log.Fatalf("storage failure: %v", errors.Unwrap(err)) // show root cause
}
log.Fatal(err)
} Defensive patterns
Strategy: try-catch
Validate before calling
// Ensure the backend is reachable before resolving:
if err := store.SearchIssueIDs(ctx, "probe", types.IssueFilter{}); err != nil {
return fmt.Errorf("storage unavailable: %w", err)
} Try / catch
id, err := utils.ResolvePartialID(ctx, store, input, cfg)
if err != nil {
var root error
for e := err; e != nil; e = errors.Unwrap(e) { root = e }
if ctx.Err() != nil { return fmt.Errorf("timed out: %w", ctx.Err()) }
log.Printf("search failure root cause: %v", root)
return err // not a not-found case; do not treat as missing issue
} Prevention
- Run `bd doctor` as a preflight to catch backend connectivity issues
- Use contexts with sane timeouts and check ctx.Err() on failure
- Keep beads and the storage backend on compatible versions (run migrations after upgrades)
- Retry once on transient network errors before surfacing to the user
When it happens
Trigger: Calling utils.ResolvePartialID (directly or via ResolvePartialIDs) when store.SearchIssueIDs errors — e.g. the database is unreachable, the underlying SQL query fails, the context is cancelled, or the storage driver returns an I/O or wire-protocol error during the substring (LIKE) search.
Common situations: Dolt/MySQL daemon not running or crashed mid-session; network drop on a remote (MySQL wire protocol) store; context timeout exceeded on very large databases; schema mismatch after a beads version upgrade; read-only or corrupted data directory.
Related errors
- not found
- load wisp labels: %w
- edge %d %s->%s: checking planned blocking cycle: %w
- reading existing dependencies for %s: %w
- searching closed gates: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/eaf80ccae6c3ab37.
Report an issue: GitHub.