gastownhall/beads · warning

pull succeeded but is_blocked recompute failed: %w

Error message

pull succeeded but is_blocked recompute failed: %w

What it means

Returned when the pull itself succeeded but the post-merge recomputation of is_blocked dependencies (recomputeBlockedAfterPull) failed. The data is merged, but derived is_blocked rows may be stale until the next sync. The error is wrapped so the operator knows the merge is fine and only the derived-state refresh broke.

Source

Thrown at internal/storage/embeddeddolt/version_control.go:664

				// empty here; the conflicts arrive captured pre-abort inside
				// MergeConflictsError instead.
				var mce *versioncontrolops.MergeConflictsError
				if errors.As(pullErr, &mce) {
					conflicts = mce.Conflicts
					return nil
				}
				return fmt.Errorf("pull from %s: %w", peer, pullErr)
			}
			return nil
		})
	})
	if err != nil || len(conflicts) > 0 {
		// Conflicted pulls skip the recompute: the operator resolves first,
		// and the next sync picks the rows up.
		return conflicts, err
	}
	if err := s.recomputeBlockedAfterPull(ctx, preHead); err != nil {
		return conflicts, fmt.Errorf("pull succeeded but is_blocked recompute failed: %w", err)
	}
	return conflicts, nil
}

// preMergeHead reads the pre-pull HEAD for the post-merge is_blocked
// recompute (bd-6dnrw.3). Empty on failure, which degrades the recompute to a
// full pass instead of skipping the hook.
func (s *EmbeddedDoltStore) preMergeHead(ctx context.Context) string {
	head, err := s.GetCurrentCommit(ctx)
	if err != nil {
		return ""
	}
	return head
}

// recomputeBlockedAfterPull recomputes the denormalized is_blocked column for
// the rows a pull's merge changed (bd-6dnrw.3) and creates a Dolt commit for
// the result. is_blocked is otherwise maintained only by local write paths, so

View on GitHub (pinned to 71377f2769)

Solutions

  1. Retry the pull (or trigger the next sync) — recompute reruns and picks the rows up
  2. Inspect the wrapped error for SQL/transaction root cause
  3. Verify dependency schema (is_blocked columns) is intact after upgrades
  4. Run a manual recompute/doctor pass to refresh derived state

Example fix

// before: treating this as a full pull failure
if err := store.PullFrom(ctx, peer); err != nil { rollbackEverything() }
// after: pull data is valid; treat as warning and resync later
if err := store.PullFrom(ctx, peer); err != nil {
    log.Warn("pull ok but blocked-recompute failed; will retry on next sync: %%v", err)
}
Defensive patterns

Strategy: try-catch

Try / catch

conflicts, err := store.PullFrom(ctx, peer)
if err != nil && strings.Contains(err.Error(), "is_blocked recompute failed") {
    log.Warn("data merged; derived state stale, retrying on next sync")
}

Prevention

When it happens

Trigger: PullFrom completes without conflicts, preMergeHead captured a pre-pull HEAD, and recomputeBlockedAfterPull errors — e.g. SQL query failure, transaction abort, or database contention during recompute.

Common situations: Heavy concurrent sync traffic locking rows during recompute; schema drift where is_blocked columns changed; crash/interruption mid-recompute leaving derived state stale.

Related errors


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