ByteStreamUploader: accept ALREADY_EXISTS

[ulfjack]

If the service returns an ALREADY_EXISTS error, then we assume that the
proper file is present remotely.

Fixes #12111.

Change-Id: I7f5af0cca2e5efea32067b092f619c6593af0aac

[ulfjack]

@EricBurnett to double-check my reasoning here.

[EricBurnett]

SGTM on the change to ignore ALREADY_EXISTS - no harm in it.

Unconvinced on servers returning it though - do we need to document anything more explicitly in the REAPI? I think semantically ALREADY_EXISTS means what it says on the tin, but I suspect most clients of the REAPI ByteStream will not special-case it today, as you're seeing here. So while I think it's completely reasonable for clients to tolerate it, I wouldn't recommend any servers return it today, not without something stronger in the API text ("SHOULD treat ALREADY_EXISTS the same as a successful upload..."). Which would take some discussion in the community.

You can get around all this by returning OK instead of ALREADY_EXISTS, including without having first read all the incoming bytes - gRPC allows this (see grpc/grpc#7032).

And so that's my recommendation in general - anywhere you're looking to return ALREADY_EXISTS you'd probably be better off returning a preemptive 'OK' instead. Most clients (including this SDK) should work out of the box with that, and I'm not aware of any semantic reason to need to return ALREADY_EXISTS (clients don't actually care, they just want to know the file is uploaded).

[ulfjack]

We are doing that right now. The reason I was looking at the code is that we have tested one closed-source client which seems to misbehave when we prematurely return OK, although we're not sure why.

[coeuvre]

@ulfjack Can you rebase and fix the tests?

[keertk]

Hi there! Thank you for contributing to the Bazel repository. We appreciate your time and effort. We're doing a clean up of old PRs and will be closing this one since it seems to have stalled. Please feel free to reopen if you’re still interested in pursuing this or if you'd like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.