gastownhall/beads · error
failed to iterate existing issues for prefix %q: %w
Error message
failed to iterate existing issues for prefix %q: %w
What it means
After scanning all matching issue ids, rows.Err() is checked; a non-nil error from the result-set iteration (e.g. connection dropped mid-scan) is wrapped with this message. The counter seeding aborts to avoid seeding from partial data.
Source
Thrown at internal/storage/dolt/issues.go:833
var id string
if err := rows.Scan(&id); err != nil {
return fmt.Errorf("failed to scan issue id: %w", err)
}
// Strip the prefix and attempt to parse the remainder as an integer.
suffix := strings.TrimPrefix(id, prefixDash)
if suffix == id {
// id did not start with prefix- (should not happen given LIKE, but be safe)
continue
}
var num int
if _, parseErr := fmt.Sscanf(suffix, "%d", &num); parseErr == nil && fmt.Sprintf("%d", num) == suffix {
if num > maxNum {
maxNum = num
}
}
}
if err := rows.Err(); err != nil {
return fmt.Errorf("failed to iterate existing issues for prefix %q: %w", prefix, err)
}
// Only insert a seed row if we found at least one numeric ID.
// If no numeric IDs exist, the counter will naturally start at 1 on first use.
if maxNum > 0 {
_, err = tx.ExecContext(ctx,
"INSERT INTO issue_counter (prefix, last_id) VALUES (?, ?)",
prefix, maxNum)
if err != nil {
return fmt.Errorf("failed to seed issue_counter for prefix %q at %d: %w", prefix, maxNum, err)
}
}
return nil
}
// nextCounterIDTx atomically increments and returns the next sequential issue ID
// for the given prefix within an existing transaction. Returns the full ID stringView on GitHub (pinned to 71377f2769)
Solutions
- Retry the operation once the connection is stable; a full re-scan will reseed correctly
- Increase connection/query timeouts for large issue tables
- Check server logs and network stability between client and Dolt server
- Verify the seeded counter afterwards (next created ID should be max+1)
Defensive patterns
Strategy: retry
Validate before calling
// Check connection stability / timeouts before long scans
if (connTimeout < 30_000) throw new Error("increase query timeout for large tables"); Try / catch
try {
await bd.create(title);
} catch (e) {
if (String(e.message).includes("failed to iterate existing issues")) {
await backoff(); // retry; full re-scan reseeds correctly
} else throw e;
} Prevention
- Set generous query timeouts for databases with many issues
- Use wired/stable network connections for remote Dolt servers
- Retry counter seeding — it is deterministic and idempotent
- Verify seeded counter (next id = max+1) after recovering from a failure
When it happens
Trigger: seedCounterFromExistingIssuesTx iterating the LIKE result set when the connection or query fails partway — network interruption, server timeout, transaction killed.
Common situations: Large databases where the scan takes long enough to hit a connection timeout; flaky network to a remote Dolt server; server restart mid-query.
Related errors
- iterate wisp dependents: %w
- failed to check issue_counter for prefix %q: %w
- failed to query existing issues for prefix %q: %w
- failed to scan issue id: %w
- failed to seed issue_counter for prefix %q at %d: %w
AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30).
Data as JSON: /api/errors/dbf1c4c4ef33ee2c.
Report an issue: GitHub.