%s of %s reported success but did not land (found assignee=%

Error message

%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

What it means

verifiedClaimWrite re-read the issue after a successful write and found the claim state did NOT change as expected: the write reported success but did not land (assignee/status mismatch the postcondition). The code emits a claimVerifyLost metric and returns this error telling the caller to treat the operation as NOT applied.

Source

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

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

Treat the operation as not applied: re-read the issue and inspect the actual assignee/status values reported in the error
If another writer claimed the issue concurrently, do not blindly retry — coordinate or pick different work
Retry the claim/update once the server is healthy, then verify again
Check for concurrent writers/sync conflicts in the Dolt database if lost writes recur

Example fix

// before
bd update bd-42 --claim
// error: found assignee="other-agent" status="open"
// after
bd ready   # pick unclaimed work, or
bd update bd-42 --claim   # only after confirming the issue is still unclaimed

Defensive patterns

Strategy: try-catch

Validate before calling

// before claiming, confirm the issue is still claimable:
iss, err := store.GetIssue(ctx, id)
if err == nil && iss.Assignee != "" && iss.Status == "in-progress" { /* already claimed */ }

Try / catch

if err := store.ClaimIssue(ctx, id, assignee); err != nil {
    if strings.Contains(err.Error(), "did not land") {
        // treat op as NOT applied; re-read actual assignee/status from the
        // error or via GetIssue, and only retry if still unclaimed
    }
}

Prevention

Coordinate concurrent agents so only one claims a given issue
Re-read the issue after a lost-write error instead of blindly retrying
Use bd ready / claim semantics to avoid double-claim races
Investigate recurring lost writes — they indicate server degradation or sync conflicts

When it happens

Trigger: claimIssue or updateIssueChecked performs write(); readClaimState succeeds but returns assignee/status not matching post.want — e.g. the update was silently lost by a degraded Dolt server, overwritten by a concurrent writer, or the commit didn't actually persist.

Common situations: Concurrent agents racing to claim the same issue (another writer claimed first); a degraded Dolt server acknowledging but dropping writes; stale reads after a replication/federation hiccup.

Related errors

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