docs(swagger): add user_id query to three cache-priming endpoints#839
Merged
raymondjacobson merged 1 commit intoMay 20, 2026
Merged
Conversation
GET /events/remix-contests, GET /users/{id}/contests, and
GET /playlists/new-releases all embed user objects (track owners /
contest hosts / album creators) in their responses, and their handlers
already call app.getMyId(c) to feed MyID into the Parallel query that
hydrates related users (does_current_user_follow etc). But their SDK
request types didn't expose a user_id query field, so the wire request
never carried the requester id and the backend computed personalization
against MyID=0 — every embedded user came back with
does_current_user_follow: false.
Clients prime those embedded users into a shared user cache
(primeRelatedData / primeCollectionData → primeUserData), and the cache
write only happens when the slot is empty, so the bad state sticks
until a personalized fetch overwrites it. Same shape as the bug fixed
for /notifications in #837 / #838.
Spec-only change. resolveMyIdMiddleware already reads ?user_id= from
the query, so the Go handlers personalize correctly as soon as clients
start sending the param.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
raymondjacobson
added a commit
to AudiusProject/apps
that referenced
this pull request
May 20, 2026
Audit follow-up to the notifications fix. Three more hooks were priming un-personalized users into the shared tan-query user cache because their SDK request types didn't expose the personalization query param: - useAllRemixContests → events.getRemixContests - useUserRemixContests → users.getContestsByUser - useNewAlbumReleases → playlists.getPlaylistsNewReleases Each handler already calls app.getMyId(c) on the backend; the param just wasn't being sent. AudiusProject/api#839 added the user_id query field to all three routes. This PR: - Regenerates @audius/sdk so each request type accepts userId?: string (additive, no breaking change). - Updates the three hooks to pass userId: Id.parse(currentUserId). After this the cache primes carry the right does_current_user_follow state out of the gate, so explore/contests/new-releases surfaces don't need a profile visit to correct the follow indicators. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Merged
3 tasks
raymondjacobson
added a commit
to AudiusProject/apps
that referenced
this pull request
May 20, 2026
…14367) ## Summary Three more hooks were priming un-personalized users into the shared user cache — same bug class as the notifications fix in [#14366](#14366). API spec change merged in [AudiusProject/api#839](AudiusProject/api#839); this PR consumes it. | Hook | SDK call | Prime | | --- | --- | --- | | `useAllRemixContests` | `events.getRemixContests` | `primeRelatedData` | | `useUserRemixContests` | `users.getContestsByUser` | `primeRelatedData` | | `useNewAlbumReleases` | `playlists.getPlaylistsNewReleases` | `primeCollectionData` → `primeUserData` | In every case the backend handler already calls `app.getMyId(c)` to feed `MyID` into the `Parallel` query that hydrates embedded users — the query param just wasn't being sent because the SDK request type didn't expose it. With no value, `MyID = 0` and the SQL [short-circuited](https://github.com/AudiusProject/api/blob/main/api/dbv1/get_users.sql.go#L129-L136) `does_current_user_follow` to false for every embedded user. Clients then primed those into a shared cache that other surfaces read. ## Changes | File | Change | | --- | --- | | `packages/sdk/src/sdk/api/generated/default/apis/EventsApi.ts` | Add `userId?: string` to `GetRemixContestsRequest`; map to `queryParameters['user_id']`. | | `packages/sdk/src/sdk/api/generated/default/apis/UsersApi.ts` | Add `userId?: string` to `GetContestsByUserRequest`; map to `queryParameters['user_id']`. Path field is still `id` (the contest host); query `userId` is the requester. | | `packages/sdk/src/sdk/api/generated/default/apis/PlaylistsApi.ts` | Add `userId?: string` to `GetPlaylistsNewReleasesRequest`; map to `queryParameters['user_id']`. | | `packages/common/src/api/tan-query/events/useAllRemixContests.ts` | Pull `currentUserId` via `useCurrentUserId`; pass as `userId`. | | `packages/common/src/api/tan-query/events/useUserRemixContests.ts` | Same. Note this hook already took a `userId` prop for the contest host — that maps to the path `id`. `currentUserId` is separately threaded as the query. | | `packages/common/src/api/tan-query/collection/useNewAlbumReleases.ts` | Pull `currentUserId`; pass as `userId`. | | `.changeset/personalization-three-endpoints.md` | Minor `@audius/sdk` bump for the new optional fields. | ## Note on the SDK files in this diff I edited the generated `*.ts` files by hand here because `npm install` in my environment was blocked by a date-pinned registry constraint, which broke `node_modules` and stopped both `gen.js` and the rollup build from running. The edits are deterministic — they replicate the exact pattern openapi-generator already produces for analogous endpoints (e.g. `GetTrendingPlaylistsRequest` in the same `PlaylistsApi.ts`). A fresh `npm run gen` on a clean checkout should produce the same diff. Worth a quick visual confirmation during review. ## Test plan - [ ] CI green (typecheck/lint/tests). - [ ] On a fresh app load with a signed-in account: explore → contests carousel, an artist's contests tab, and browse → new albums all show correct Following state for surfaced artists without first having to navigate to each profile. - [ ] Network inspector on each of the three endpoints carries `?user_id=<hashed-current-user-id>` and `does_current_user_follow: true` for users actually followed in `related.users` / collection owners. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds an optional
user_idquery parameter to three routes that embed user objects in their response and rely onapp.getMyId(c)to personalize them. Today the SDK request types don't expose this field, so clients never send?user_id=and the backend computes personalization againstMyID = 0— i.e.does_current_user_followand friends return false for every embedded user.GET /events/remix-contests(v1_events_remix_contests.go:187,195,215)GET /users/{id}/contests(v1_users_contests.go:114,122,142)GET /playlists/new-releases(v1_playlists_new_releases.go:74)Why
Audit follow-up to #837 / #838 (notifications). Same bug class:
related.users(or a collection'suserfield).MyID: app.getMyId(c)intodbv1.ParallelParamsto personalize those users.getMyId(c)reads from the query string?user_id=. With no query value,MyID = 0and the SQL short-circuitsdoes_current_user_followto false.primeRelatedDatafor remix-contests,primeCollectionData→primeUserDatafor new-releases). The cache write only happens when the slot is empty, so once poisoned the entry sticks until the user navigates to that profile and a personalized fetch overwrites it.Affected client hooks:
useAllRemixContests(apps/packages/common/src/api/tan-query/events/useAllRemixContests.ts)useUserRemixContests(apps/packages/common/src/api/tan-query/events/useUserRemixContests.ts)useNewAlbumReleases(apps/packages/common/src/api/tan-query/collection/useNewAlbumReleases.ts)Spec-only change
resolveMyIdMiddlewarealready readsc.Query(\"user_id\")globally (resolve_middleware.go:24-28), so the Go handlers personalize correctly as soon as the SDK starts sending the param. No backend code change required, no Go test updates required.No path-placeholder collision this time — all three routes are either query-only (
new-releases,remix-contests) or already useidas the path placeholder (users/{id}/contests). The generator will emit a cleanuserId?: stringfield.Test plan
?user_id=<hashed-current-user-id>anddoes_current_user_follow: truefor users actually followed inrelated.users.🤖 Generated with Claude Code