Recover transient initial object-store claims - #38
igor-ladkin wants to merge 1 commit into
Conversation
85b79ad to
5c30d55
Compare
| %StoredState{meta: %Meta{} = attempted_meta}, | ||
| encoded | ||
| ) do | ||
| with {:ok, %{body: ^encoded, etag: etag}} <- |
There was a problem hiding this comment.
we are pinning on ^encoded but shouldn't we be matching on our own etag instead?
There was a problem hiding this comment.
@chrismccord TL;DR; It's the same check the put-path recovery already does, just shared now.
Initially the change was purely mechanical to reuse the same resolution logic we have in resolve_ambiguous_conditional_put for try_claim. I've checked the path again after you mentioned. I don't fully understand how we can match on etag. Ours only comes back on the 2xx of the PUT that committed, and that's exactly the response we lost (existing path). The retry just gets a 412. The one we do hold (the If-Match etag) is the version before our write, so it can't tell our write apart from someone else's. Claims don't even have that one. I mean, we could predict that etag would be some kind of hash but it doesn't feel right. Please correct if I'm missing anything significant 🙇♂️.
Initial object-store claims fail on a single dropped connection, including when the write committed but its response was lost. Retry transient claim failures twice, then reconcile ambiguous results only when stored bytes and the complete boot owner match the attempted claim.