Failed deletes in cached_db session backend should log, just like failed writes

[Jacob Walls]

The Security Team closed a report about the cached_db session backend, but in so doing, we noticed that we ​recently documented logging any such exceptions for failed writes.

We should handle failed deletes as well, see #34806, which only touched save(), not delete(). (Starting off as "bug" since the docs imply no save-versus-delete distinction, to my ear.)

Thanks LocalHost for the informative report.

[Natalia Bidart]

Thanks!

[Vismay]

Opened PR: ​https://github.com/django/django/pull/21606

I reproduced the cache delete failure locally and added sync/async regression tests. The PR makes cached_db delete failures non-fatal and logs them consistently with save failures.

[Vishy]

Just a heads-up:

While logging failed writes in the cache_db session backend is certainly necessary, I believe it would also be appropriate to log the model.DoesNotExist exception in django.contrib.sessions.backends.db—the backend from which cache_db inherits.

That's currently being skipped. It might be out of scope for this ticket.

    def delete(self, session_key=None):
        if session_key is None:
            if self.session_key is None:
                return
            session_key = self.session_key
        try:
            self.model.objects.get(session_key=session_key).delete()
        except self.model.DoesNotExist:
            pass # <-- silently ignored

[Vismay]

Thanks! I'd lean to keeping this ticket scoped to the cache-delete logging, mirroring what #34806 did for save(). The DoesNotExist handling in the db backend looks intentional to me — deleting a session that's already gone is a normal no-op rather than an error worth logging — so I'd leave it as-is here. Happy to open a separate ticket if a maintainer feels it's worth logging.

[Jacob Walls <jacobtylerwalls@…>]

In a486b48d:

Fixed #37210 -- Logged cached_db session cache delete failures.