storage/objects: TestObjects failed

[flaky-bot[bot]]

trafficstars

Note: #2885 was also for this test, but it was closed more than 10 days ago. So, I didn't mark it flaky.

---

commit: f2e5277497d1dd2c6f4d435fadbf486382680bae buildURL: Build Status, Sponge status: failed

[flaky-bot[bot]]

Looks like this issue is flaky. :worried:

I'm going to leave this open and stop commenting.

A human should fix and close this.

---

When run at the same commit (f2e5277497d1dd2c6f4d435fadbf486382680bae), this test passed in one build (Build Status, Sponge) and failed in another build (Build Status, Sponge).

[tritone]

Error:

    objects_test.go:148: downloadUsingRequesterPays: Object("foo.txt").NewReader: storage: object doesn't exist

Based on the test I don't really see how this flake should be possible as a standalone, given that the object is also queried in the previous lines. Maybe some subtlety with requester pays; @BrennaEpp can you take this?

[BrennaEpp]

I'll take a look

[BrennaEpp]

This is weird...

• There are no metadata updates to cause errors with delayed propagation, and as @tritone mentions, this object is used before (and after) in the test without failure.
• It's using the same project that owns the bucket for billing, so there really shouldn't be any permission issues.
• The upload is done using preconditions so it should be idempotent (and in any case it should error if it fails to upload).
• I don't see any operations that would cause side effects causing flakiness, but it's hard to tell since there is so much going on and different buckets being interspersed in the test.

I think what I'm going to do here is separate out this part of the test which will make it obvious that nothing else is going on if it fails again.

[BrennaEpp]

Bumping down priority as the issue is not related to requesterpays and requires instead some changes to testutil instead (these are in progress).