ready claim of %s reported success but could not be verified

Error message

ready claim of %s reported success but could not be verified (server degraded?): %w — re-read the issue before trusting the claim

What it means

verifiedReadyClaim re-reads an issue from the server after a successful ready-claim write; if the verification read itself fails while in server mode, the success cannot be trusted. The library returns the underlying read error wrapped in this message, instructing the caller to re-read before trusting the claim.

Source

Thrown at internal/storage/dolt/issues.go:433

// (bd-zccb9): the claimed ID is only known once the write body has run, so
// this cannot ride verifiedClaimWrite's id parameter — but the resolution
// protocol is the same. Split from ClaimReadyIssue so injection tests can
// drive the write seam directly, the same way the verifiedClaimWrite tests do.
//
// Successful ready claims verify the winning plane because IncludeEphemeral
// may select a wisp. An indeterminate commit response remains indeterminate:
// assignee and status cannot prove the lease and actor-attributed event landed.
func (s *DoltStore) verifiedReadyClaim(ctx context.Context, actor string, write func() (*types.Issue, error)) (*types.Issue, error) {
	claimed, err := write()
	if err != nil {
		return nil, err
	}
	if claimed == nil || !s.serverMode {
		return claimed, err
	}
	assignee, status, verr := s.readReadyClaimState(ctx, claimed.ID)
	if verr != nil {
		return nil, fmt.Errorf("ready claim of %s reported success but could not be verified (server degraded?): %w — re-read the issue before trusting the claim",
			claimed.ID, verr)
	}
	post := claimedBy(actor)
	if post.want(assignee, status) {
		return claimed, nil
	}
	doltMetrics.claimVerifyLost.Add(ctx, 1, metric.WithAttributes(
		attribute.String("op", "ready-claim")))
	return nil, fmt.Errorf("ready claim of %s reported success but did not land (found assignee=%q status=%q, want %s) — server likely degraded; treat the claim as NOT applied",
		claimed.ID, assignee, status, post.desc)
}

// HeartbeatIssue refreshes the lease on an issue actor holds in_progress,
// pushing lease_expires_at forward on its row in the ephemeral leases table
// (see issueops.lease). Deliberately NO DOLT_ADD/DOLT_COMMIT: the leases
// table is dolt_ignored, so a heartbeat mints no commit and no history — this
// is the whole point of bd-lrgn1 (fleet heartbeats were the dominant source
// of unbounded reachable history). Wrapped in withRetryTx so a heartbeat that

View on GitHub (pinned to 71377f2769)

Solutions

Re-read the issue (or retry the ready claim) to learn its actual assignee/status
Retry the whole claim operation; the store uses retry transactions, so a transient read failure often clears on retry
Check that the Dolt SQL server is reachable and healthy (bd doctor, connection settings)
If verification keeps failing, treat the claim as unverified and avoid making decisions based on it

Defensive patterns

Strategy: retry

Validate before calling

// Before trusting any claim, verify server reachability
const healthy = await checkServerHealth(); // e.g. run a trivial query
if (!healthy) throw new Error("server unavailable; do not claim");

Type guard

function isVerifiedClaim(result) {
  return result !== null && typeof result === "object" && result.id && !String(result.message ?? "").includes("could not be verified");
}

Try / catch

try {
  const claimed = await bd.readyClaim(actor);
} catch (e) {
  if (String(e.message).includes("could not be verified")) {
    const issue = await bd.show(id); // re-read before trusting
    // decide whether to retry the claim
  } else throw e;
}

Prevention

Ensure the Dolt server is healthy and reachable before claim loops
Retry claims on transient verification failures with backoff
Never act on a claim until its state has been re-read
Monitor server logs for errors between write and read

When it happens

Trigger: A bd ready --claim (or equivalent storage call) succeeds on the write path, but the subsequent readReadyClaimState query fails due to a transient server/connection error, while s.serverMode is true.

Common situations: Dolt server restart or network blip between the claim write and verification read; server-side connection pool exhaustion; timeouts under load.

Related errors

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