Fix cache poisoning when a singleton write is rolled back

[alessio-b2c2]

The bug

SingletonModel keeps the configured cache (SOLO_CACHE) in sync with the DB by updating it synchronously around every DB operation. If an operation runs inside an outer transaction.atomic() that later rolls back, the database reverts but the cache keeps the value it was given. The cache then disagrees with the DB until SOLO_CACHE_TIMEOUT expires (5 minutes by default) or the next successful write — so get_solo() serves stale (or non-existent) data in the meantime.

There are three poisoning paths in solo/models.py:

1. save() called self.set_to_cache() immediately after super().save(). A rollback reverts the row but the cache keeps the rolled-back value. (Model.objects.create() routes through save(), so it's covered too.)
2. delete() called self.clear_cache() before super().delete(). A rollback keeps the row, but the cache was already emptied — so the cache is stale/empty for a row that still exists.
3. get_solo() on a cache miss did get_or_create(pk=...) then obj.set_to_cache(). This poisons the cache in two sub-cases: the row was created inside the transaction (and then rolled away), or the row existed but had an uncommitted modification earlier in the same transaction that get_solo read back and cached before the rollback.

The fix

Defer every cache update to transaction.on_commit(...):

• save() → transaction.on_commit(self.set_to_cache)
• delete() → transaction.on_commit(self.clear_cache)
• get_solo() (cache miss) → transaction.on_commit(obj.set_to_cache)

on_commit callbacks fire when the surrounding transaction commits and are discarded on rollback, so the cache only ever reflects what the DB actually committed. In autocommit mode (no surrounding transaction) the callback fires immediately, so non-transactional behaviour is unchanged.

For get_solo() this is both simpler and more correct than capturing get_or_create's created flag and skipping the cache for new rows: deferring to commit closes the create-on-miss rollback case and the read-of-uncommitted-modification case, with no flag to track. The only behavioural change is that within a still-open transaction the cache isn't populated until commit (repeated reads hit the DB until then); the common autocommit path is unaffected.

Tests

Added a TransactionRollbackCacheTest (solo/tests/tests.py) with a regression test per path:

• save() inside an atomic() that rolls back → cache must not hold the rolled-back value.
• delete() inside an atomic() that rolls back → cache must still hold the (not-actually-deleted) value.
• get_solo() create-on-miss inside an atomic() that rolls back → cache must not hold an object for the row that no longer exists.
• get_solo() re-caching an uncommitted modification inside an atomic() that rolls back → cache must not hold the rolled-back value.

The tests:

• use TransactionTestCase (not TestCase) — on_commit callbacks don't fire inside the wrapping transaction a plain TestCase uses, which would make the fixes look broken;
• run with SOLO_CACHE enabled — the fixes are no-ops when caching is off, since set_to_cache/clear_cache early-return.

I verified each new test fails against the unfixed models.py and passes with the fix. The existing test_delete_if_cache_enabled was updated to wrap save()/delete() in captureOnCommitCallbacks(execute=True), since its cache assertions now depend on the deferred on_commit callbacks firing.

Full suite (manage.py test solo), ruff format/ruff check, and mypy all pass.

🤖 Generated with Claude Code