Notifications endpoint#53
Conversation
Omitting all the timestamp_offset, group_id_offset, valid_types stuff for now.
| -- 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.
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). |




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.