3 ms·
> For new objects, you get read-after-write consistency and the example you gave contradicts that. Mind the documented caveat for this case: > The caveat is t
by Dunedan 6y ago
> For new objects, you get read-after-write consistency and the example you gave contradicts that.
Mind the documented caveat for this case:
> The caveat is that if you make a HEAD or GET request to a key name before the object is created, then create the object shortly after that, a subsequent GET might not return the object due to eventual consistency.
- dividuum 6y agoIndeed, although that seems irrelevant for the mentioned use case. After all, why would the client request an image before it's uploaded. It seems like a straight forward "server side upload->generate url and send it to client->client requests image" flow. It's perfectly covered by the consistency provided.
- fxtentacle 6y agoThat's what we did. Server side upload, link into websocket, client downloads image. It did work 99.99% of all requests.
- Dunedan 6y agoI'm surprised about the conclusion of the AWS support that this is intended behavior. I'm curious about the specifics of the behavior of S3 in this case. Do you have any more detailed information from the AWS support you could share by any chance? If you don't mind, I'd be also grateful if you could drop some answers to the questions below. Do you use S3 replication (CRR/SRR)? Before uploading, do you make any request to the object key? If yes, what kind of request? For downloading, do you use pre-signed URLs or is the S3 bucket public? What's the error the 0,01% of users encounter? Is it a NoSuchKey error?