Skip to content

[Fix] Notifications related.users: hydrate with viewer perspective#836

Open
dylanjeffers wants to merge 2 commits into
mainfrom
claude/nice-franklin-b87a00
Open

[Fix] Notifications related.users: hydrate with viewer perspective#836
dylanjeffers wants to merge 2 commits into
mainfrom
claude/nice-franklin-b87a00

Conversation

@dylanjeffers
Copy link
Copy Markdown
Contributor

Summary

  • /v1/notifications/:userId builds a related.users block via queries.Parallel, but passed MyID = app.getMyId(c) — which reads the (typically absent) user_id query param and defaults to 0. With my_id = 0, get_users.sql short-circuits does_current_user_follow/does_current_user_subscribe to false for every related user.
  • On this endpoint the path-param :userId IS the viewer, so we now pass userId through as MyID.
  • Symptom that prompted this: profile pages opened from a notification showed "Follow" for accounts the viewer already followed.
  • Added a regression test (TestV1Notifications_RelatedUsersViewerPerspective) that seeds a follow + two repost notifications and asserts does_current_user_follow is true for the followed actor and false for the unfollowed actor in related.users. Verified by reverting the fix: the test fails with expected: true / actual: false exactly on the follow assertion.

The client-side workaround in apps#14361 can be dropped once this ships.

Test plan

  • go test -count=1 -run 'TestV1Notifications' ./api/ — all 13 notification tests pass
  • Confirmed new test fails on main's behavior (reverted the fix locally, re-ran, assertion fired)
  • Verify in staging that opening a profile from a notification renders the correct follow state

🤖 Generated with Claude Code

dylanjeffers and others added 2 commits May 15, 2026 12:47
…uthors

The previous shadow-ban filter on the contest discovery list used
`aggregate_user.score < 0` (AAO output). Two problems:

  1. `aggregate_user` has no index covering `score`, so the CTE forced a
     full seq scan on every cold call. /v1/events/remix-contests?status=all
     was hanging ~22s cold-cache (warm: ~100ms).
  2. The AAO signal is a separate moderation lane from the community
     karma-reports system that already governs comment visibility.
     The two can drift.

Fix: align the contest filter with the comment-visibility filter. A host
is shadow-banned from contest discovery if they authored a comment that
crossed the same `high_karma_reporters` threshold (sum of reporters'
follower_count >= karmaCommentCountThreshold) that hides the comment
itself on v1_track_comments / v1_event_comments. The new CTE
`karma_reported_authors` lifts the comment-level signal up to user_id.

`muted_by_karma` is unchanged — still filters hosts muted by high-karma
users.

`comment_reports` is a small table indexed on `comment_id`, and the new
CTE only adds a hash-join on comments (PK lookup per hkr row), so the
cost is bounded by report volume rather than user-table size — no
sequential scan over millions of aggregate_user rows.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ed.users

The /v1/notifications/:userId related.users block was hydrated with
MyID=0 because getMyId reads the (absent) user_id query param. With
my_id=0 the SQL short-circuits does_current_user_follow/_subscribe to
false, so profile pages opened from a notification showed "Follow" for
accounts the viewer already followed.

The path-param userId IS the viewer on this endpoint, so thread it
through to ParallelParams.MyID instead.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.

1 participant