Skip to content

feat(api): embed pending collaborator invites on the owner's own tracks#947

Merged
raymondjacobson merged 1 commit into
mainfrom
claude/collab-pending-collaborators
Jun 10, 2026
Merged

feat(api): embed pending collaborator invites on the owner's own tracks#947
raymondjacobson merged 1 commit into
mainfrom
claude/collab-pending-collaborators

Conversation

@raymondjacobson

Copy link
Copy Markdown
Member

Backend for the apps edit-form fix: an owner editing a track was dropping still-pending collaborator invites, because the edit form seeds its collaborators field from the track response — which only carried accepted collaborators. On save, the ETL reconciles the metadata set and removes any invite not present, so pending ones vanished.

Change

  • GetTrackCollaborators now returns accepted and pending rows (with status). The embed splits them:
    • collaborators — accepted, on every track response (unchanged behavior).
    • pending_collaboratorsnew, populated only on the requester's own tracks.
  • Owner-scoped: pending user IDs are resolved and embedded only where owner == my_id, so pending invites never surface to other viewers. (They're public on-chain regardless, but there's no reason to hand them to everyone.)
  • swagger: pending_collaborators declared on the track schemas.

Follow-up (apps)

The edit form will initialize from collaborators + pending_collaborators so saving preserves pending invites. Needs an SDK regen once this deploys (the field reproduces cleanly, same as collaborators).

Tests

TestPendingCollaboratorsVisibleToOwnerOnly: owner sees the pending invite; a non-owner sees only the accepted collaborator. Existing collaborator/embed/profile suites still pass.

Perf

Same bounded, index-served embed query as before (PK leads on track_id, ANY(@ids)); it now also returns pending rows, post-filtered by the same index. No new round-trips.

🤖 Generated with Claude Code

The edit form initializes its collaborators field from the track response, which
only carried accepted collaborators — so re-saving a track dropped any
still-pending invites (the ETL reconciles the metadata set and removes rows not
present). Expose the owner's pending invites so the client can preserve them.

- GetTrackCollaborators now returns accepted + pending (with status); the embed
  splits them: `collaborators` (accepted) on every response as before, plus a
  new `pending_collaborators` populated only on the requester's own tracks.
- Owner-scoped: pending user IDs are resolved and embedded only for tracks where
  owner == my_id, so pending invites never surface to other viewers.
- swagger: declare `pending_collaborators` on the track schemas.

Test: owner sees the pending invite, non-owner sees only accepted.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
raymondjacobson added a commit to AudiusProject/apps that referenced this pull request Jun 10, 2026
The edit form seeded its collaborators field from the track's accepted-only
`collaborators`, so saving dropped any still-pending invites (the ETL reconciles
the metadata set). Initialize the field from accepted + pending instead.

- SDK Track/SearchTrack: add `pendingCollaborators` (hand-edit stopgap; the API
  swagger now declares `pending_collaborators` in AudiusProject/api#947, so the
  next regen reproduces this).
- Track model + adapter: expose `pending_collaborators` (owner-only).
- Web + mobile edit screens: seed the collaborators field with
  `[...collaborators, ...pending_collaborators]` so pending invites survive a
  save. Display still uses accepted-only `collaborators` (no regression).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@raymondjacobson raymondjacobson merged commit 1ad2042 into main Jun 10, 2026
5 checks passed
@raymondjacobson raymondjacobson deleted the claude/collab-pending-collaborators branch June 10, 2026 00:37
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