Skip to content

Notifications endpoint#53

Merged
stereosteve merged 14 commits intomainfrom
sp-notifs
Jul 17, 2025
Merged

Notifications endpoint#53
stereosteve merged 14 commits intomainfrom
sp-notifs

Conversation

@stereosteve
Copy link
Copy Markdown
Contributor

@stereosteve stereosteve commented Apr 25, 2025

TODO:

  • Do we need all the timestamp_offset, group_id_offset query logic? Does the client use some, all or none of those query params?
  • playlist_id is weirdly a list, as discussed here: Fix marshalling for playlist notifs apps#11562
  • Ordering of items inside of actions array may diverge. Will need a subquery there.
  • The seen_at is never null in the golang version.. not sure why that's different.
  • Need the unread count field

Questions:

  • Difference in seen_at null behavior?
  • limit=0 returns results from python server?
  • playlist_id as array... is that for the client or for the python?

Changes:

  • Added valid_types support, buttimestamp_offset and group_id_offset query logic is problematic and I don't understand what it's supposed to do.

@stereosteve
Copy link
Copy Markdown
Contributor Author

Existing prod:

image

vs golang:

image

@stereosteve stereosteve marked this pull request as ready for review July 16, 2025 18:23
Copy link
Copy Markdown
Member

@raymondjacobson raymondjacobson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally lgtm

Comment thread api/server.go Outdated
Comment thread trashid/hashify_json_test.go Outdated
Comment thread trashid/hashify_json_test.go Outdated
Comment thread api/v1_notifications.go
Comment thread api/v1_notifications.go
-- name: GetNotifs :many
WITH user_seen as (
SELECT
LAG(seen_at, 1, now()::timestamp) OVER ( ORDER BY seen_at desc ) AS seen_at,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know about LAG... that's super cool, though isn't this backwards? shouldn't the lag be prev_seen_at?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Member

Existing prod:

image vs golang: image

What is this Un Minuto track? This data in these screenshots does look a little strange. 89 new uploads? when was the last seen at for this account?

@stereosteve
Copy link
Copy Markdown
Contributor Author

What is this Un Minuto track? This data in these screenshots does look a little strange. 89 new uploads? when was the last seen at for this account?

This is stereosteve... I don't often open notifs drawer so there are large gaps in my notification_seen:

 2025-07-16 16:34:04
 2025-04-23 20:32:11
 2025-04-03 04:14:02
 2025-04-02 13:37:51
 2025-03-28 20:05:52
 2025-03-27 14:01:45

I think all the new coop tracks between 04-23 and 7-16 get grouped into that one row in that case... which for coop records seems accurate.

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).

@stereosteve stereosteve merged commit 77289aa into main Jul 17, 2025
3 checks passed
@stereosteve stereosteve deleted the sp-notifs branch July 17, 2025 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants