gastownhall/beads · error

hydrate ready row %s: dependency counts: %w

Error message

hydrate ready row %s: dependency counts: %w

What it means

HydrateReadyRowInTx failed to read dependency counts for the just-claimed issue via GetDependencyCountsInTx. Per the function's contract, a failed count read is an error, not a silent zero, so the entire claim transaction is unwound rather than returning an issue that looks dependency-free.

Source

Thrown at internal/storage/issueops/claim_next.go:92

}

// HydrateReadyRowInTx fills in the relationship cardinalities a ready row
// carries, reading them in the caller's transaction so the counts describe the
// state that transaction is about to commit.
//
// A failed count read is an error rather than a zero. The CLI's pre-role
// hydration swallowed all three, which meant a broken database reported a
// claimed issue with no dependencies rather than saying the read failed; here
// the whole claim rolls back instead, because a result nobody can hydrate is
// not a result.
func HydrateReadyRowInTx(ctx context.Context, tx *sql.Tx, issue *types.Issue) (*types.IssueWithCounts, error) {
	if issue == nil {
		return nil, nil
	}
	ids := []string{issue.ID}
	depCounts, err := GetDependencyCountsInTx(ctx, tx, ids)
	if err != nil {
		return nil, fmt.Errorf("hydrate ready row %s: dependency counts: %w", issue.ID, err)
	}
	records, err := GetDependencyRecordsForIssuesInTx(ctx, tx, ids)
	if err != nil {
		return nil, fmt.Errorf("hydrate ready row %s: dependency records: %w", issue.ID, err)
	}
	commentCounts, err := GetCommentCountsInTx(ctx, tx, ids)
	if err != nil {
		return nil, fmt.Errorf("hydrate ready row %s: comment counts: %w", issue.ID, err)
	}

	issue.Dependencies = records[issue.ID]
	counts := depCounts[issue.ID]
	if counts == nil {
		counts = &types.DependencyCounts{}
	}
	var parent *string
	for _, dep := range records[issue.ID] {
		if dep.Type == types.DepParentChild {

View on GitHub (pinned to 71377f2769)

Solutions

1. Inspect the wrapped cause (errors.Unwrap / %w chain) to find the underlying SQL failure
2. Retry the claim once the database connection or server is healthy — the claim rolled back so no partial state persists
3. Verify the dependencies table exists and the schema is current (bd doctor / migration check)

Example fix

result, err := store.ClaimNext(ctx, req)
if err != nil && strings.Contains(err.Error(), "dependency counts") {
	// underlying DB read failed; claim rolled back — safe to retry after health check
	if dbErr := checkDBHealth(ctx, store); dbErr == nil {
		result, err = store.ClaimNext(ctx, req)
	}
}

if err := store.Ping(ctx); err != nil {
	return fmt.Errorf("database unavailable before claim: %w", err)
}

result, err := store.ClaimNext(ctx, req)
if err != nil && strings.Contains(err.Error(), "dependency counts") {
	// claim rolled back; safe to retry once DB is healthy
	if retryErr := waitForDB(ctx, store); retryErr == nil {
		result, err = store.ClaimNext(ctx, req)
	}
}

When it happens

Trigger: ExecuteClaimNext -> HydrateReadyRowInTx where the dependency-count query fails: broken/corrupt database, connection loss mid-transaction, lock contention, or a missing dependencies table.

Common situations: Database backend degraded or restarted during a claim; schema missing the dependencies table after a botched migration; network blip on a remote Dolt server.

Related errors

• descendants: hydrate issues: %w
• descendants: hydrate wisps: %w
• search %s: hydrate: %w
• hydrate labels: %w
• hydrate dependencies: %w

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