Somewhat speculative, but the change in f62a9769fd, while fixing
certain errors where logged-out users sometimes didn't have sessions
come calc_users, also opened the possibility of certain request
sequences that wouldn't give a user a session.
In the interest of conservatism, we create a session if not exists
in both the new location in calc_users and the previous spot in
before_request.
Consider the case of the current /notifications filter condition:
WHERE ... NOT ((comments.sentto = 2) AND (users.is_muted))
SELECT 1 WHERE NOT ((null = 2) AND (true)); ⇒ 0 rows
SELECT 1 WHERE NOT ((1 = 2) AND (true)); ⇒ 1 row
SELECT 1 WHERE NOT ((2 = 2) AND (true)); ⇒ 0 rows
We want the first expression, where comments.sentto = null, to evaluate
to false, not to null, so it negates to true. Behavior as written is:
SELECT 1 WHERE NOT ((null = 2) AND (true)); →
SELECT 1 WHERE NOT (null AND true); →
SELECT 1 WHERE NOT null; →
SELECT 1 WHERE null;
Which guarantees a null return set. If we check first for non-nullity:
SELECT 1 WHERE NOT ((null IS NOT null) AND (null = 2) AND (true)); ⇒ 1
SELECT 1 WHERE NOT ((1 IS NOT null) AND (1 = 2) AND (true)); ⇒ 1
SELECT 1 WHERE NOT ((2 IS NOT null) AND (2 = 2) AND (true)); ⇒ 0
ghostarchive has been giving us 500 backs lately. They are making
an absolute mess of the log for a non-central, opportunistic feature,
and we already eat exceptions for archive.org. We merely extend that
to ghostarchive.
Currently relies on Sub.__repr__ in many cases, which was causing
errors when concatenated. Switched to concatenation using `~` also,
just in anticipation of future errors.
justcool393
Snakes
SneedBot
Aevann1