tests/test_wtsite_session_lock.py::test_clear_cookies_under_concurrency_is_safe on branch fix-parallelization-silent-drop (#132) fails on every OS with Python 3.10 and passes on 3.11, 3.12 and 3.13.
E assert [AttributeError("'NoneType' object has no attribute 'name'"),
E AttributeError("'NoneType' object has no attribute 'name'")] == []
tests/test_wtsite_session_lock.py:87: AssertionError
Example run: https://github.com/OpenSemanticLab/osw-python/actions/runs/32710857726/job/97381737205
What the test does. Four clearer threads repopulate the jar under ws._session_lock and then call ws._clear_cookies(). Two reader threads run list(jar) in a tight loop without holding the lock. Exactly two AttributeErrors are collected, one per reader, so the failure is on the read side, not in _clear_cookies.
The underlying question is a design decision, not a test bug. RequestsCookieJar iteration on 3.10 can yield None when a cookie is removed concurrently. _clear_cookies serialises writers against each other, but it cannot make an unsynchronised external read of site.connection.cookies safe. So either:
WtSite only guarantees safety for its own synchronised access. The test's unlocked reader is then testing something WtSite never promised, and the reader should take the lock (or the test should be dropped).WtSite guarantees the jar is safe for any concurrent reader, including mwclient's own internal reads during a request. That requires replacing the jar with a lock-wrapping subclass, not just locking _clear_cookies.
Option 2 is the stronger claim and is arguably what the fix is for: mwclient reads those cookies on every request, from threads osw does not control. Worth deciding before merging #132.
Blocking: #132 cannot go green as-is.
tests/test_wtsite_session_lock.py::test_clear_cookies_under_concurrency_is_safeon branchfix-parallelization-silent-drop(#132) fails on every OS with Python 3.10 and passes on 3.11, 3.12 and 3.13.Example run: https://github.com/OpenSemanticLab/osw-python/actions/runs/32710857726/job/97381737205
What the test does. Four
clearerthreads repopulate the jar underws._session_lockand then callws._clear_cookies(). Tworeaderthreads runlist(jar)in a tight loop without holding the lock. Exactly twoAttributeErrors are collected, one per reader, so the failure is on the read side, not in_clear_cookies.The underlying question is a design decision, not a test bug.
RequestsCookieJariteration on 3.10 can yieldNonewhen a cookie is removed concurrently._clear_cookiesserialises writers against each other, but it cannot make an unsynchronised external read ofsite.connection.cookiessafe. So either:WtSiteonly guarantees safety for its own synchronised access. The test's unlockedreaderis then testing somethingWtSitenever promised, and the reader should take the lock (or the test should be dropped).WtSiteguarantees the jar is safe for any concurrent reader, including mwclient's own internal reads during a request. That requires replacing the jar with a lock-wrapping subclass, not just locking_clear_cookies.Option 2 is the stronger claim and is arguably what the fix is for: mwclient reads those cookies on every request, from threads osw does not control. Worth deciding before merging #132.
Blocking: #132 cannot go green as-is.