ef8b2a5f32
We can't reliably return 404 for POST if there's a any missing primary response, but we'll DO it ... with a quorum of 404s ... but ONLY if we don't have proof of the object existing (i.e. a single 202 will spoil the 404). To offset the obvious increased server errors somewhat, and deal with special cases when one PUT lands on a handoff - we'll *also* in this same change add extra backend POST requests to handoffs when we observed mixed primary 202/404 response on POST. The reasoning being if we can just get > quorum 202 responses from *somewhere* we can actually call the POST successful and durable despite some 404s. A future change to the object server could in theory make the proxy more confident about a 404 in the face of an *out-of-date* rouge 202 - IF the object-server POST responses started included a timestamp - but this code would still be as-correct-as-possible for the upgrade path and there's really nothing to be done if the *only* non-202 storage server responses are "no useful information"/missing (so again, a single 202 should STILL spoil a quorum of *missing* 404; b/c who's posting to non-existent objects - we know it WAS there?) Closes-Bug: #2119675 Change-Id: I43644f242d1cca416844dbd556d40f4e8cd869f9 Co-Authored-By: Jianjian Huo <jhuo@nvidia.com> Signed-off-by: Clay Gerrard <clay.gerrard@gmail.com>
14 KiB
14 KiB