tests show that if the code is really broken, we have
5 or more connections lingering here, so for less than two
(it's usually one) just clean it out and consider it as GC noise.
To test this better we also open up the windows/mac archs that
were disabled for greenlet
Fixes: #13102
Change-Id: Iccf419e7f345bcae4a388d222ab69fc792a3c1ca
(cherry picked from commit
ff2c7668fe90b43b75dcb0d6e7651349dd715e5a)
pytest-args: "-k 'not test_autocommit_on and not test_turn_autocommit_off_via_default_iso_level and not test_autocommit_isolation_level'"
exclude:
- # cext-greenlet only runs on ubuntu x64 and arm64
- - build-type: "cext-greenlet"
- os: "windows-latest"
- - build-type: "cext-greenlet"
- os: "windows-11-arm"
- - build-type: "cext-greenlet"
- os: "macos-latest"
# the threaded pythons are not stable under greenlet. Even
# though we can run individual tests, when you run the whole suite
if pool.base._strong_ref_connection_records:
ln = len(pool.base._strong_ref_connection_records)
pool.base._strong_ref_connection_records.clear()
- assert (
- False
- ), "%d connection recs not cleared after test suite" % (ln)
+
+ if ln > 2:
+ # allow two connections to linger, as on loaded down
+ # CI hardware there seem to be occasional GC lapses that
+ # are not easily preventable
+ assert (
+ False
+ ), "%d connection recs not cleared after test suite" % (ln)
if config.options and config.options.low_connections:
# for suites running with --low-connections, dispose the "global"
# engines to disconnect everything before making a testing engine