{"record":{"id":"cc3e78ff845c0c70","repo":"gastownhall/beads","slug":"s-of-s-reported-success-but-could-not-be-verifie","errorCode":null,"errorMessage":"%s of %s reported success but could not be verified (server degraded?): %w — re-read the issue before trusting the %s","messagePattern":"(.+?) of (.+?) reported success but could not be verified \\(server degraded\\?\\): %w — re-read the issue before trusting the (.+?)","errorType":"error_code","errorClass":null,"httpStatus":null,"severity":"error","filePath":"internal/storage/dolt/claim_verify.go","lineNumber":202,"sourceCode":"\n// verifiedClaimWrite runs write and resolves its outcome against the database\n// state per the protocol above.\n//\n// A verify that contradicts a reported success can in principle also be a\n// legitimate concurrent mutation (a forced unclaim landing within the\n// verification window). That reads as a lost write and fails loudly too —\n// acceptable: the caller must re-establish its view either way.\nfunc (s *DoltStore) verifiedClaimWrite(ctx context.Context, id string, post claimPostcondition, write func() error) error {\n\tif !s.serverMode || s.isActiveWisp(ctx, id) {\n\t\treturn write()\n\t}\n\terr := write()\n\tif err != nil {\n\t\treturn err\n\t}\n\tassignee, status, verr := s.readClaimState(ctx, id)\n\tif verr != nil {\n\t\treturn fmt.Errorf(\"%s of %s reported success but could not be verified (server degraded?): %w — re-read the issue before trusting the %s\",\n\t\t\tpost.op, id, verr, post.op)\n\t}\n\tif post.want(assignee, status) {\n\t\treturn nil\n\t}\n\tdoltMetrics.claimVerifyLost.Add(ctx, 1, metric.WithAttributes(\n\t\tattribute.String(\"op\", post.op)))\n\treturn 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\",\n\t\tpost.op, id, assignee, status, post.desc, post.op)\n}\n","sourceCodeStart":184,"sourceCodeEnd":213,"githubUrl":"https://github.com/gastownhall/beads/blob/71377f276968b452ee607177637970a4ff888584/internal/storage/dolt/claim_verify.go#L184-L213","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","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"],"exampleFix":"// before\nbd update bd-42 --claim   # reports success but unverifiable\n// after\nbd show bd-42             # re-read to confirm actual assignee/status\n# retry claim only if it did not land","handlingStrategy":"try-catch","validationCode":"// pre-check server health before claim/update writes:\n// issue a cheap read (bd show <id>); if reads are failing, defer writes","typeGuard":null,"tryCatchPattern":"if err := store.ClaimIssue(ctx, id, assignee); err != nil {\n    if strings.Contains(err.Error(), \"could not be verified\") {\n        // the write MAY have landed: re-read the issue first\n        iss, rerr := store.GetIssue(ctx, id)\n        if rerr == nil && wantClaimed(iss) { return nil } // already applied\n        // otherwise wait for server stability and retry once\n    }\n}","preventionTips":["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"],"tags":["dolt","verification","server-degraded","write-consistency"],"backgroundTag":"write-verification-failed","analyzedSha":"71377f276968b452ee607177637970a4ff888584","analyzedAt":"2026-08-30T18:55:39.744Z","schemaVersion":2},"datasetVersion":"2026-08-30T23:17:21.991Z"}