gastownhall/beads · error

iterate inbound dependencies from %s: %w

Error message

iterate inbound dependencies from %s: %w

What it means

DeleteResolvedSetInTx aborts when rows.Err() reports a failure after iterating an inbound-dependency result set. Unlike a scan error, this happens after the loop — the driver hit an I/O or protocol error while streaming rows (e.g. connection dropped mid-result-set). The failing dependency table is named in the message.

Source

Thrown at internal/storage/issueops/delete.go:269

			if err != nil {
				if optionalBlockedTable(depTable) && isTableNotExistError(err) {
					continue
				}
				return nil, fmt.Errorf("count inbound dependencies from %s: %w", depTable, err)
			}
			for rows.Next() {
				var issID string
				if err := rows.Scan(&issID); err != nil {
					_ = rows.Close()
					return nil, fmt.Errorf("scan inbound dependency: %w", err)
				}
				if !deletedSet[issID] {
					depsCount++
				}
			}
			_ = rows.Close()
			if err := rows.Err(); err != nil {
				return nil, fmt.Errorf("iterate inbound dependencies from %s: %w", depTable, err)
			}
		}
	}

	result.DependenciesCount = depsCount
	result.LabelsCount = labelsCount
	result.EventsCount = eventsCount
	result.DeletedCount = len(set.RegularIDs) + len(set.WispIDs)

	if dryRun {
		return result, nil
	}

	affectedIssues, affectedWisps, aerr := AffectedByDeletionInTx(ctx, tx, set.RegularIDs, set.WispIDs)
	if aerr != nil {
		return nil, fmt.Errorf("affected by batch delete: %w", aerr)
	}

View on GitHub (pinned to 71377f2769)

Solutions

1. Unwrap to see whether it's a timeout, connection reset, or server-side kill.
2. Retry with a longer context timeout or smaller delete batches.
3. Check Dolt server logs for query kills around the failure.
4. Improve network reliability or run the delete locally against the database.

Example fix

// before
ctx := context.Background()
res, err := store.DeleteIssuesInTx(ctx, tx, ids)
// after
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute)
defer cancel()
res, err := store.DeleteIssuesInTx(ctx, tx, ids)

if err := db.PingContext(ctx); err != nil {
    return fmt.Errorf("connection unhealthy before large delete: %w", err)
}
// ensure generous deadline
if dl, ok := ctx.Deadline(); !ok || time.Until(dl) < 30*time.Second {
    return errors.New("give inbound-dependency scans at least 30s")
}

res, err := store.DeleteIssuesInTx(ctx, tx, ids)
if err != nil && strings.Contains(err.Error(), "iterate inbound dependencies") {
    return retryWithBackoff(3, func() error {
        ctx2, cancel := context.WithTimeout(context.Background(), 5*time.Minute)
        defer cancel()
        _, err = store.DeleteIssuesInTx(ctx2, tx, ids)
        return err
    })
}

When it happens

Trigger: Calling DeleteIssuesInTx/DeleteInTx where a large inbound-dependency result set is being streamed and the connection resets, the server kills the query, or the context deadline expires before iteration finishes.

Common situations: Very large dependency graphs with a short context timeout; Dolt server query timeout or memory limit; network instability between client and server.

Related errors

• remaining blocker rows from %s: %w
• blocker edge rows from %s: %w
• check issue existence in %s: rows: %w
• stale issues rows: %w
• row iteration error: %w

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