Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add missing await on delete_blob call per issue 459 #460

Merged
merged 4 commits into from
Mar 21, 2024
Merged

add missing await on delete_blob call per issue 459 #460

merged 4 commits into from
Mar 21, 2024

Conversation

johnmacnamararseg
Copy link
Contributor

per #459

add missing await on delete_blob

@johnmacnamararseg
Copy link
Contributor Author

tested this locally and appears to run fine. unsure if further testing is required

@TomAugspurger
Copy link
Contributor

Thanks, I think a unit test would be helpful to avoid future regressions. Can you add one?

@johnmacnamararseg
Copy link
Contributor Author

@TomAugspurger yea sure thing

@johnmacnamararseg
Copy link
Contributor Author

johnmacnamararseg commented Feb 12, 2024

This issue might be a little more impactful than I originally thought. I initially thought we were just leaking the runtime warning but still cleaning up the directories. However, it looks like without await none of those delete_blob calls on the directory markers are executing - which makes sense since were attempting to execute these co-routines without await. Ran some local tests to confirm this.

I also didn't realize that this test suite could run out of the azurite container - pretty nifty.

This change actually breaks this unit test

It looks like this test and the one above it are mocking the delete_blob calls to assert that the various calls within rm run in a certain order and then setting the side affect to delete_blob so that the delete occurs. The reason this didn't fail the test originally and didn't produce the runtime warning was because the mocking + side effect turned the delete_blob call from a co-routine requiring the await into a conventional subroutine.

All the files created in the storage harness are still deleted since the side effect delete_blob call exists outside of the async context manager in _rm_files. However, once I added await it doesn't seem like mock_delete_blob captures all of the delete_blob calls like we would expect. I don't yet have an explanation for this.

Going to see if I can modify these tests in a way where we can still evaluate the call ordering but the combination of Mocking + async is a bit out of my wheelhouse

)
def test_rm_recursive2(mock_delete_blob, storage):
@pytest.mark.filterwarnings("error")
def test_rm_recursive2(storage):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I modified this test to remove the mocking so the delete_blob calls are executed asynchronously. This test ensures that the files in data/rootare in fact removed. Also, the decorator will raise the RuntimeWarning emitted from the missing await (regression).

assert "data/root" not in fs.ls("/data")

with pytest.raises(FileNotFoundError):
fs.ls("data/root")

last_deleted_paths = [call.args[1] for call in mock_delete_blob.mock_calls[-7:]]

async def test_rm_recursive_call_order(storage, mocker):
Copy link
Contributor Author

@johnmacnamararseg johnmacnamararseg Feb 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since fs.rm validates that the files are actually removed, there wasn't an easy way to mock delete_blob so that still ran the deletes asynchronously as a side effect (someone might have a clever way to do this). So instead I just explicitly supply the file paths under data/root , call fs._rm_files, and assert the call order similar to how the previous test was working

@johnmacnamararseg
Copy link
Contributor Author

@TomAugspurger changes pushed

@johnmacnamararseg
Copy link
Contributor Author

@TomAugspurger @efiop any chance we can get some eyes on this?

@TomAugspurger TomAugspurger merged commit 350eea7 into fsspec:main Mar 21, 2024
@TomAugspurger
Copy link
Contributor

Thanks @johnmacnamararseg!

@nosterlu
Copy link

Thank you for fixing @johnmacnamararseg, I did not notice that folders were not deleted until you mentioned it. Looking forward to this release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants