Conversation
🦋 Changeset detectedLatest commit: 3700822 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Pull request overview
Fixes playlist/album publishing and updating flows to align with recent SDK ID and metadata schema changes, ensuring playlist creation/update works with client expectations and correct image fields.
Changes:
- Allow preset
playlistIdin create-playlist metadata and tightenonProgresstyping for playlist uploads. - Refactor
createPlaylistInternalto parse inputs internally and normalize progress events for image uploads. - Fix playlist/album publish flow to stop incorrectly converting returned track IDs; update playlist update schema to use
playlistImageSizesMultihash.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
packages/sdk/src/sdk/api/playlists/types.ts |
Updates playlist create/update zod schemas (preset playlistId, progress handler typing, playlistImageSizesMultihash). |
packages/sdk/src/sdk/api/playlists/PlaylistsApi.ts |
Refactors create-playlist entity-manager path and normalizes onProgress callbacks for cover art uploads. |
packages/common/src/api/tan-query/upload/usePublishCollection.ts |
Stops mis-parsing published track IDs when building playlistContents for album/playlist creation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const { userId, imageFile, metadata, onProgress } = await parseParams( | ||
| 'createPlaylistInternal', | ||
| CreatePlaylistSchema | ||
| )(params) |
There was a problem hiding this comment.
createPlaylistInternal parses CreatePlaylistSchema but then ignores playlistId and trackIds from the parsed result (it only reads metadata.playlistId). This is a functional regression for callsites that rely on trackIds to populate playlistContents, and for callers that pass playlistId at the top level. Consider: (1) destructuring playlistId and trackIds from the parsed params, (2) choosing the entity id from params.playlistId ?? metadata.playlistId ?? generatePlaylistId(), and (3) populating metadata.playlistContents from trackIds when provided (as uploadPlaylist does) to preserve existing behavior.
| metadata.playlistContents = publishedTracks | ||
| .filter((t) => !!t.trackId) | ||
| .map((t) => ({ | ||
| timestamp: Math.round(Date.now() / 1000), | ||
| trackId: t.trackId!, |
There was a problem hiding this comment.
Filtering out items where trackId is falsy will silently create an album with missing tracks if any track publish failed (previously this would error when trying to parse/convert the missing id). It’s safer to fail the mutation when any published track is missing trackId (or has an error) so the user doesn’t end up with a partially-created collection.
| metadata.playlistContents = publishedTracks | ||
| .filter((t) => !!t.trackId) | ||
| .map((t) => ({ | ||
| timestamp: Math.round(Date.now() / 1000), | ||
| trackId: t.trackId!, |
There was a problem hiding this comment.
Filtering out items where trackId is falsy will silently create a playlist with missing tracks if any track publish failed (previously this would error when trying to parse/convert the missing id). It’s safer to fail the mutation when any published track is missing trackId (or has an error) so the user doesn’t end up with a partially-created collection.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
publishTracksreturns string track IDs, which were being incorrectly parsed as though they were numbers that needed converting. This was changed behavior from recent SDK changes made to match the POST endpoints as this was working previouslycreatePlaylistwasn't equipped to handle using a presetplaylistIdlike our client expects, rejecting calls that hadplaylistIdalready set in the metadata (which would happen on our creation of playlists from scratch).createPlaylistInternalwas being passed parsed parameters in thecreatePlaylistcase, and unparsed in theuploadPlaylistcase, and used types that made it hard to squeeze both callsites in. This was resulting in incorrectly setting some IDs to hash IDs (eg inplaylistContents) and was uncovered when fixing the playlistId bug aboveupdatePlaylisthad incorrect schema still referencingcoverArtCidinstead ofplaylistImageSizesMultihash, blocking any playlist updates that included an image update