binary_sha3_384: A file with this exact same content has already been uploaded
Can someone please check if this was an intentional change, because from my point of view the old error message describes the reason much better than the generic Error checking upload uniqueness message that is used now.
This hasn’t really changed, I can see a few specific conditions under which the first message would appear, but in most cases when uploading snaps, the second (and preferred) one should show.
Concretely, the second message would appear if one of the services handling snap signatures returned an error.
Can you tell me whether you see the first message usually, sporadically, or only saw it once?
Also, if you can provide an exact date/time when you got the first message, I can go checking our logs to see what the problem might have been.
I saw binary_sha3_384: Error checking upload uniqueness. reliably the other day, having accidentally pushed a revision to the wrong track (latest), I went to reupload it (snapcraft upload --release right-track/stable file.snap) and kept getting the error message. I thought this was unfortunate because I had to rebuild the entire package just to change the hash which was a waste of time for both me and the store.
Grant, there might have been a way to have just pushed the package to the right track anyway but I couldn’t find anything.
If you already got a revision number, you can just release it to the correct track snapcraft release the-snap the-revision --channel=right-track/stable). You don’t need to go reuploading a revision which was already accepted and assigned a revision number.
The behavior you describe suggests the service I mentioned earlier started having trouble when you wanted to reupload your build. It’s an unfortunate coincidence but it sounds like the right explanation.
As per above, if you do have a more precise timestamp I can maybe narrow down the timeframe and look for a clearer cause for this.
Can’t say for sure, but it looks like I’ve been getting this error periodically over the past few months, and I think it happens quite often (~1-3 of 5 tries I guess).
Thank you. ~12:20 UTC today, upload id e489382f-f626-4cc5-ac65-8aa369c66640.
Thanks for the hint Daniel, I expected a simple solution but the Google-fu wasn’t particularly helpful for me that day.
I suppose my issue is pretty unrelated to OP’s because it was entirely deterministic and a mae culpa, but if you did want to look into it, the uploads would have been on 2021-09-16 at around ~15:00 UTC, give or take a few hours, on the root-framework snap, with revision 319 being the snap I’d tried to reupload.
FWIW I checked and found one of our service units was somewhat io-starved, which may have explained why the backend for that particular service was taking too long to respond, making the other service give up and error out to you folks. Apologies. I’ve replaced the unit in question with a better one, and also reset alerts on our side so 1) this shouldn’t happen again, 2) if it does I’ll hear about it and take action.
@roadmr, Hi! I faced with this problem again (around 3 a.m. Oct 23), upload id 1664697a-b5f6-4861-878b-0dca8bce01a9, can you please take a look on this one more time?
@roadmr Hi again! It happened again 2 times, at around ~07:02 UTC for the upload id c0a89d8c-1b7f-4c64-a0fd-af38676ea042, and at around ~09:00 UTC for the upload id 3a789d74-6e96-4c25-9eb5-77119b3fa6fc. I guess this is a known issue, and therefore I will try to somehow handle it on my side. Thanks for the help anyway!
