gastownhall/beads · error

iterate dependents from %s: %w

Error message

iterate dependents from %s: %w

What it means

After consuming all rows from a dependents query, rows.Err() reported a failure that only becomes visible at the end of iteration — typically a dropped connection or cancelled context mid-result-set. The wrapper names the table whose iteration broke. All successfully scanned rows before the failure are discarded and the delete aborts.

Source

Thrown at internal/storage/issueops/delete_role.go:225

				return nil, fmt.Errorf("query dependents from %s: %w", depTable, err)
			}
			for rows.Next() {
				var target, dependent string
				if err := rows.Scan(&target, &dependent); err != nil {
					_ = rows.Close()
					return nil, fmt.Errorf("scan dependent: %w", err)
				}
				if idSet[dependent] {
					continue
				}
				if bySource[target] == nil {
					bySource[target] = make(map[string]bool)
				}
				bySource[target][dependent] = true
			}
			_ = rows.Close()
			if err := rows.Err(); err != nil {
				return nil, fmt.Errorf("iterate dependents from %s: %w", depTable, err)
			}
		}
	}

	out := make(map[string][]string, len(bySource))
	for target, dependents := range bySource {
		out[target] = workapi.SortedDeleteIDs(dependents)
	}
	return out, nil
}

// deleteNeighborsInTx hydrates the SURVIVING rows joined to the deletion set
// by a dependency edge in either direction — the rows whose text the deletion
// rewrites.
//
// One query per plane over the whole set, so a `--from-file` batch costs two
// queries rather than two per deleted id.
//

View on GitHub (pinned to 71377f2769)

Solutions

1. Retry the delete with a fresh transaction; the operation is read-only at this stage and idempotent
2. Increase the context timeout for large batches
3. Check network stability and server logs for aborted connections
4. Reduce deleteBatchSize so each result set streams quickly
5. Run deletes close to the database rather than over a WAN

Example fix

// before
ctx := context.Background()
store.Delete(ctx, req)
// after
cctx, cancel := context.WithTimeout(context.Background(), 60*time.Second)
defer cancel()
store.Delete(cctx, req)

if err := ctx.Err(); err != nil { return err } // ensure budget before large batch

err := store.Delete(ctx, req)
if err != nil && strings.Contains(err.Error(), "iterate dependents from") {
    // deferred rows.Err(); retry with fresh tx and longer timeout
}

When it happens

Trigger: ExternalDependentsBySourceInTx finishes the rows.Next() loop over dependencies/wisp_dependencies and rows.Err() is non-nil — network interruption, server-side abort, or context cancellation during result streaming.

Common situations: Flaky network to a remote Dolt/MySQL server; context deadline expiring mid-iteration on a very large batch; server killing a long-running query.

Related errors

• iterate neighbors from %s: %w
• failed to iterate issues for prefix %q: %w
• dolt server connection failed: %w
• failed to iterate peers for migration: %w
• failed to iterate existing issues for prefix %q: %w

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