storage.it.ITStorageTest: testBlobReload failed #853
Assignees
Labels
api: storage
Issues related to the googleapis/java-storage API.
flakybot: flaky
Tells the Flaky Bot not to close or comment on this issue.
flakybot: issue
An issue filed by the Flaky Bot. Should not be added manually.
priority: p1
Important issue which blocks shipping the next release. Will be fixed prior to next release.
🚨
This issue needs some love.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Comments
flaky-bot
bot
added
flakybot: issue
product-auto-label
bot
added
the
api: storage
|
Looks like this issue is flaky. 😟 I'm going to leave this open and stop commenting. A human should fix and close this. When run at the same commit (accf502), this test passed in one build (Build Status, Sponge) and failed in another build (Build Status, Sponge). |
flaky-bot
bot
added
the
flakybot: flaky
tritone
added a commit
to tritone/java-storage
that referenced
this issue
Jun 3, 2021
It looks like the text for this error on the backend has changed (sometimes) from "Precondition Failed" to "At least one of the pre-conditions you specified did not hold". I don't think it's really necessary to check the exact message in any case given that we do check for a code of 412, which implies a precondition failure. Fixes googleapis#853
tritone
added a commit
that referenced
this issue
Jun 7, 2021
It looks like the text for this error on the backend has changed (sometimes) from "Precondition Failed" to "At least one of the pre-conditions you specified did not hold". I don't think it's really necessary to check the exact message in any case given that we do check for a code of 412, which implies a precondition failure. I added a check of the error Reason instead, which is more standardized. Fixes #853
danielduhh
pushed a commit
that referenced
this issue
Jun 17, 2021
It looks like the text for this error on the backend has changed (sometimes) from "Precondition Failed" to "At least one of the pre-conditions you specified did not hold". I don't think it's really necessary to check the exact message in any case given that we do check for a code of 412, which implies a precondition failure. I added a check of the error Reason instead, which is more standardized. Fixes #853
danielduhh
added a commit
that referenced
this issue
Jun 17, 2021
* feat: configure initial sp version * fix(test): update blob paths used in storage.it.ITStorageTest#testDownloadPublicBlobWithoutAuthentication (#759) Port of googleapis/google-cloud-go#3806 Fixes #755 * test: remove error string matching (#861) It looks like the text for this error on the backend has changed (sometimes) from "Precondition Failed" to "At least one of the pre-conditions you specified did not hold". I don't think it's really necessary to check the exact message in any case given that we do check for a code of 412, which implies a precondition failure. I added a check of the error Reason instead, which is more standardized. Fixes #853 Co-authored-by: BenWhitehead <BenWhitehead@users.noreply.github.com> Co-authored-by: Chris Cotter <cjcotter@google.com>
BenWhitehead
added a commit
that referenced
this issue
Sep 28, 2021
* feat: Remove client side vaildation for lifecycle conditions (#816) * Remove client side vaildation for lifecycle conditions * fix lint and suggest updating (cherry picked from commit 5ec84cc) * fix: update BucketInfo translation code to properly handle lifecycle rules (#852) Fixes #850 (cherry picked from commit 3b1df1d) * fix: improve error detection and reporting for BlobWriteChannel retry state (#846) Add new checks to ensure a more informative error than NullPointerException is thrown if the StorageObject or it's size are unable to be resolved on the last chunk. Fixes #839 (cherry picked from commit d0f2184) * fix: correct lastChunk retry logic in BlobWriteChannel (#918) Add new method StorageRpc#queryResumableUpload which allows getting a shallow StorageObject for a resumable upload session which is complete. Update BlobWriteChannel to use StoageRpc#queryResumableUpload instead of StorageRpc#get when attempting to validate the upload size of an object when it determines the upload is complete and is on the last chunk. If a BlobWriteChannel is opened with a conditional like IfGenerationMatch it is not possible to simply get the object, as the object can drift generationally while the resumable upload is being performed. Related to #839 (cherry picked from commit ab0228c) * test: remove error string matching (#861) It looks like the text for this error on the backend has changed (sometimes) from "Precondition Failed" to "At least one of the pre-conditions you specified did not hold". I don't think it's really necessary to check the exact message in any case given that we do check for a code of 412, which implies a precondition failure. I added a check of the error Reason instead, which is more standardized. Fixes #853 (cherry picked from commit 146a3d3) Co-authored-by: JesseLovelace <43148100+JesseLovelace@users.noreply.github.com> Co-authored-by: Chris Cotter <cjcotter@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This test failed!
To configure my behavior, see the Flaky Bot documentation.
If I'm commenting on this issue too often, add the
flakybot: quietlabel andI will stop commenting.
commit: accf502
buildURL: Build Status, Sponge
status: failed
Test output
The text was updated successfully, but these errors were encountered: