Don't destroy the session when the account lookup returns None#49
Merged
czpython merged 2 commits intoJul 21, 2026
Merged
Conversation
resolve_session_account dropped the session whenever Account.get(account_id) returned None — added in ENG-703 as cleanup for a "deleted account". But nothing deletes accounts (no code path, and the account FKs are ON DELETE RESTRICT), so that case can't happen legitimately. The guard only ever fires on an anomaly — a transient/ambiguous lookup miss — and in exactly that case destroying the session turns a momentary blip into a forced re-login. Remove the drop. A None still 401s the request; the session survives so a transient miss self-heals on the next request. Regression test asserts a missing-account lookup leaves the session key intact.
czpython
deleted the
commonzenpython/remove-session-drop-on-missing-account
branch
July 21, 2026 06:57
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
resolve_session_accountdropped the session wheneverAccount.get(account_id)returnedNone— added in ENG-703 (#15) as cleanup for a "deleted account":But nothing deletes accounts — there's no code path, and every account FK is
ON DELETE RESTRICT, so an account with any login/run/usage can't be removed. The "account is gone" case the guard defends can't happen legitimately.So the guard only ever fires on an anomaly — a transient/ambiguous lookup miss — and in exactly that case, destroying the session is the wrong response: it turns a momentary blip into a forced re-login. This bit prod (2026-07-20): a session's account lookup transiently returned
None, the session was dropped, and the operator was logged out despite the account being perfectly present.Change
Remove the drop. A
Nonestill401s that one request (current_session_accountraises), but the session survives — so a transient miss self-heals on the next request instead of forcing a re-login. New regression test asserts a missing-account lookup leaves the session key intact.Verification
ruff/ruff format/pyrightclean.test_auth.pyfull suite green (12 passed), including the newtest_missing_account_does_not_drop_the_session.test_redis_eviction_signs_out_but_keeps_credentials(real session-key loss → 401 is still correct; that path is untouched).Related: the transient-
Nonetrigger itself (whyAccount.getreturnedNoneunder a concurrent request burst) is a separate open thread that needs request-level logging to pin — this PR removes the destructive amplifier, not that root.