So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

ℹ️ Googlers: Go here for more info.

I've created #7478 to track the flaky systest, which I believe is unrelated to the changes in this PR (I cannot reproduce locally).

The flaky module tear-down for storage system tests is unrelated: I've reported it in #7505.

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

ℹ️ Googlers: Go here for more info.

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

Thank you for this! Is there a timeframe on when we can expect this to appear in a pypi release of google-cloud-storage?

FYI this broke some of our tests - potentially on us but posting at least for others.

Now if a process has a blob and it's overwritten, blob.exists() is False. It used to be true.

Specifically, this was our fixture:

@pytest.fixture()
def existing_blob_name(project, bucket, blob_name_expanded, data):
    blob = gcs.client(project).get_bucket(
        bucket).blob(blob_name_expanded)
    blob.upload_from_string(dill.dumps(data))
    assert blob.exists()
    yield blob.name
    blob.delete()

This was our test (for an internal wrapper method):

def test_set_overwrite(existing_blob_name, bucket, project):
    # could do this with a parameter but so small
    with pytest.raises(ValueError):
        gcs.set(existing_blob_name, 'abc', bucket=bucket,
                project=project, overwrite=False)

    gcs.set(existing_blob_name, 'abc', bucket=bucket,
            project=project, overwrite=True)

This failed on blob.delete(), since the newly written blob has a different generation