Uh oh!
There was an error while loading. Please reload this page.
Notifications endpoint - #53
Conversation
Omitting all the timestamp_offset, group_id_offset, valid_types stuff for now.
stereosteve
commented
Jul 16, 2025
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| -- name: GetNotifs :many | ||
| WITH user_seen as ( | ||
| SELECT | ||
| LAG(seen_at, 1, now()::timestamp) OVER ( ORDER BY seen_at desc ) AS seen_at, |
There was a problem hiding this comment.
I didn't know about LAG... that's super cool, though isn't this backwards? shouldn't the lag be prev_seen_at?
There was a problem hiding this comment.
Yeah this does look backwards... it was mostly taken verbatim from get_notifications.py
I think it would be more correct to just flip the names tho... I'll try that out.
There was a problem hiding this comment.
Ok I get it now... the query is ordered by seen_at desc...
so with that ordering, the row before the current row is a greater timestamp.
seen_at | prev_seen_at ----------------------------+---------------------
2025-07-17 14:27:25.609154 | 2025-07-17 06:54:29
2025-07-17 06:54:29 | 2025-07-17 02:52:34
2025-07-17 02:52:34 | 2025-07-17 01:23:07
2025-07-17 01:23:07 | 2025-07-17 01:22:56
2025-07-17 01:22:56 | 2025-07-16 22:55:05
2025-07-16 22:55:05 | 2025-07-16 20:05:05
So I think the logic and naming is OK.
raymondjacobson
commented
Jul 16, 2025
stereosteve
commented
Jul 17, 2025
This is I think all the new coop tracks between Un Minuto is actually a private track... so we do notifs for private tracks... but that's existing behavior on the write side (in the triggers). |
Uh oh!
There was an error while loading. Please reload this page.




TODO:
timestamp_offset, group_id_offsetquery logic? Does the client use some, all or none of those query params?playlist_idis weirdly a list, as discussed here: Fix marshalling for playlist notifs apps#11562actionsarray may diverge. Will need a subquery there.seen_atis never null in the golang version.. not sure why that's different.Questions:
seen_atnull behavior?Changes:
valid_typessupport, buttimestamp_offsetandgroup_id_offsetquery logic is problematic and I don't understand what it's supposed to do.