gastownhall/beads · error

ErrBlockedRecomputeDirtyGraph

ErrBlockedRecomputeDirtyGraph

Error message

is_blocked recompute needs a clean working set

What it means

ErrBlockedRecomputeDirtyGraph signals that a full is_blocked recompute was requested while the committable graph tables (issues, dependencies) had uncommitted working-set changes. Running the recompute dirty would sweep unrelated edits into the repair commit or commit flags derived from uncommitted data, so GuardBlockedRecomputeWorkingSet refuses; callers wrap the sentinel with the offending table names.

Source

Thrown at internal/storage/issueops/blocked_consistency.go:28

	"strings"
)

// blockedRecomputeGraphTables are the version-controlled tables a full
// is_blocked recompute reads and folds into its issues-only repair commit.
//
// The dolt-ignored wisp tables (wisps, wisp_dependencies) are deliberately
// excluded. They are never staged or committed, so dirty wisp state cannot leak
// into the repair commit; and because Dolt reports every ignored table as
// perpetually "modified" in dolt_status, guarding on them would refuse the
// recompute in any workspace that has ever created a wisp. is_blocked derived
// from wisp state is the same working-set-derived value every local write path
// already produces.
var blockedRecomputeGraphTables = []string{"issues", "dependencies"}

// ErrBlockedRecomputeDirtyGraph reports that a full is_blocked recompute was
// asked to run while its committable graph tables had uncommitted changes.
// Callers wrap it with the offending table names.
var ErrBlockedRecomputeDirtyGraph = errors.New("is_blocked recompute needs a clean working set")

// GuardBlockedRecomputeWorkingSet refuses a full is_blocked recompute when the
// committable graph tables (issues, dependencies) have uncommitted working-set
// changes (bd-6dnrw.37). The recompute derives is_blocked from the current graph
// and stages only `issues`, so running it dirty would either sweep unrelated
// issue edits into the repair commit or commit flags derived from uncommitted
// dependency edits that are not part of the same commit. Run it as the first
// statement inside the recompute's own transaction so it sees exactly the
// working set the recompute will read. Returns a wrapped
// ErrBlockedRecomputeDirtyGraph naming the dirty tables, or nil when clean.
func GuardBlockedRecomputeWorkingSet(ctx context.Context, tx DBTX) error {
	dirty, err := dirtyBlockedRecomputeGraphTables(ctx, tx)
	if err != nil {
		return fmt.Errorf("check working set before is_blocked recompute: %w", err)
	}
	if len(dirty) == 0 {
		return nil
	}

View on GitHub (pinned to 71377f2769)

Solutions

  1. Commit or discard the pending working-set changes to issues/dependencies, then rerun the recompute
  2. Inspect the wrapped error for the offending table names and commit only that table's changes via the normal commit path
  3. Use isRecomputeDirtyGraphErr/dirtyGraphErr to detect this condition programmatically and prompt the user to commit first

Example fix

// before
if err := recomputeAllBlocked(ctx); err != nil { return err }
// after
if err := recomputeAllBlocked(ctx); err != nil {
    if isRecomputeDirtyGraphErr(err) {
        return fmt.Errorf("commit pending changes first: %w", err)
    }
    return err
}
Defensive patterns

Strategy: type-guard

Validate before calling

// before running the recompute, ensure the working set is clean:
// commit or discard pending changes to issues and dependencies tables

Type guard

func isDirtyGraphErr(err error) bool { return isRecomputeDirtyGraphErr(err) }

Try / catch

if err := recomputeAllBlocked(ctx); err != nil {
    if isRecomputeDirtyGraphErr(err) {
        return fmt.Errorf("commit or discard pending issues/dependencies changes, then retry: %w", err)
    }
    return err
}

Prevention

When it happens

Trigger: Calling the full is_blocked recompute (RecomputeAllBlocked path) when GuardBlockedRecomputeWorkingSet finds dirty rows in the 'issues' or 'dependencies' tables — e.g. uncommitted issue edits or dependency changes staged in the working set.

Common situations: A `bd` repair/consistency command run while other uncommitted changes exist in the working set; a crash or interrupted command left staged changes; concurrent edits not yet committed to Dolt.

Related errors


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