%s of %s reported success but could not be verified (server

Error message

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

What it means

verifiedClaimWrite performs a write then re-reads the claim state (assignee/status) to verify the write landed. This error means the write() call returned success but the verification re-read itself failed (readClaimState errored) — typically a degraded or flapping Dolt server. The operation's actual effect is unknown, so the caller is told to re-read the issue before trusting it.

Source

Thrown at internal/storage/dolt/claim_verify.go:202

// verifiedClaimWrite runs write and resolves its outcome against the database
// state per the protocol above.
//
// A verify that contradicts a reported success can in principle also be a
// legitimate concurrent mutation (a forced unclaim landing within the
// verification window). That reads as a lost write and fails loudly too —
// acceptable: the caller must re-establish its view either way.
func (s *DoltStore) verifiedClaimWrite(ctx context.Context, id string, post claimPostcondition, write func() error) error {
	if !s.serverMode || s.isActiveWisp(ctx, id) {
		return write()
	}
	err := write()
	if err != nil {
		return err
	}
	assignee, status, verr := s.readClaimState(ctx, id)
	if verr != nil {
		return fmt.Errorf("%s of %s reported success but could not be verified (server degraded?): %w — re-read the issue before trusting the %s",
			post.op, id, verr, post.op)
	}
	if post.want(assignee, status) {
		return nil
	}
	doltMetrics.claimVerifyLost.Add(ctx, 1, metric.WithAttributes(
		attribute.String("op", post.op)))
	return fmt.Errorf("%s of %s reported success but did not land (found assignee=%q status=%q, want %s) — server likely degraded; treat the %s as NOT applied",
		post.op, id, assignee, status, post.desc, post.op)
}

View on GitHub (pinned to 71377f2769)

Solutions

Re-read the issue (`bd show <id>`) to determine whether the claim/update actually landed before retrying
Retry the operation if verification shows it did not apply — be aware it may already have applied, so check first
Check Dolt server health and logs; restart or reconnect if the server is degraded
Rely on WithRetryTx/circuit-breaker recovery: wait for the server to stabilize and the breaker to allow retries

Example fix

// before
bd update bd-42 --claim   # reports success but unverifiable
// after
bd show bd-42             # re-read to confirm actual assignee/status
# retry claim only if it did not land

Defensive patterns

Strategy: try-catch

Validate before calling

// pre-check server health before claim/update writes:
// issue a cheap read (bd show <id>); if reads are failing, defer writes

Try / catch

if err := store.ClaimIssue(ctx, id, assignee); err != nil {
    if strings.Contains(err.Error(), "could not be verified") {
        // the write MAY have landed: re-read the issue first
        iss, rerr := store.GetIssue(ctx, id)
        if rerr == nil && wantClaimed(iss) { return nil } // already applied
        // otherwise wait for server stability and retry once
    }
}

Prevention

Always re-read the issue after an unverifiable write before retrying
Avoid rapid claim/update bursts against a degraded server
Monitor Dolt server logs/restarts; add readiness checks before writes
Handle transient read failures with bounded backoff before concluding the write failed

When it happens

Trigger: updateIssueChecked, claimIssue, or a similar op runs write() successfully, then readClaimState(ctx, id) fails — connection drop right after commit, server restart mid-sequence, or a transient query error — triggering this wrapped error with post.op and the issue id interpolated.

Common situations: Dolt server restarting under load; flaky network to a remote Dolt; timeouts immediately following a commit during server degradation; agents issuing rapid claim/update sequences against a struggling server.

Related errors

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