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

[3.4.0] test_access_after_del fails with Python 3.13 #1834

Closed
olebole opened this issue Sep 19, 2024 · 3 comments · Fixed by #1835
Closed

[3.4.0] test_access_after_del fails with Python 3.13 #1834

olebole opened this issue Sep 19, 2024 · 3 comments · Fixed by #1835

Comments

@olebole
Copy link
Contributor

olebole commented Sep 19, 2024

We currently test-build all packages for Python 3.13, where the python-asdf package failed . When running the CI test during build, the test_access_after_del test fails (with 3.12.6, the test passes):

___________________________ test_access_after_del _____________________________
tmp_path = PosixPath('/tmp/pytest-of-debusine-worker/pytest-0/test_access_after_del0')

    def test_access_after_del(tmp_path):
        fn = tmp_path / "test.asdf"
    
        arr = np.arange(42)
        tree = {"a": {"b": arr}}
        asdf.AsdfFile(tree).write_to(fn)
    
        with asdf.open(fn, lazy_tree=True) as af:
            d = af["a"]
    
        del af
    
>       with pytest.raises(asdf.exceptions.AsdfLazyReferenceError, match="Failed to resolve"):
E       Failed: DID NOT RAISE <class 'asdf.exceptions.AsdfLazyReferenceError'>

The other tests pass.

This was reported as Debian#1082195.

System information

asdf version: 3.4.0
python version: 3.13.0rc2
operating system: Debian testing+experimental

@braingram
Copy link
Contributor

braingram commented Sep 19, 2024

Thanks for opening the issue.

Oddly we haven't seen this failure so far in our CI tests using 3.13. I think there's a way to make that test more robust and I'll try to use the run you linked (Thanks!) to reproduce it.

Is it possible to skip that test for packaging 3.4.0 until we can make a new release?

@olebole
Copy link
Contributor Author

olebole commented Sep 19, 2024

There is no urgent need to act, because we don't have Python 3.13 yet in our unstable archive, and I don't know the timeline when it will be. If we start to move to 3.13 with our packages and there is no fix, I will just disable the test.

@braingram
Copy link
Contributor

Thanks! I do see our CI used rc1 and your run used rc2. That should give me a place to get started.

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 a pull request may close this issue.

2 participants