test_clear_cookies_under_concurrency_is_safe fails on Python 3.10 only (PR #132) #144

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:

1. 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).
2. 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.