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 string

View on GitHub (pinned to 71377f2769)

Solutions

  1. Retry the operation once the connection is stable; a full re-scan will reseed correctly
  2. Increase connection/query timeouts for large issue tables
  3. Check server logs and network stability between client and Dolt server
  4. 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

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


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