Skip to main content
← Back to list
01Issue
BugClosedSwamp ClubPublic
AssigneesNone

Relationships

#1205 Dead code: CollectivesSection island (pending-invite prompt) is never mounted; listPendingInvitationsByEmail has no production consumer

Opened by keeb · 7/17/2026

There is a fully-built "you were invited to X" prompt UI that is never rendered, and a query built to power it that nothing calls.

Details

  • islands/CollectivesSection.tsx renders pendingInvites: PendingInviteView[] with accept/decline rows, but a repo-wide search shows it is never imported or mounted anywhere. The "My Collectives" page routes/orgs.tsx only calls listUserCollectives(sessionUser.id) (memberships), and routes/profile.tsx has no collective/invite section — so a pending invitee sees nothing in-app.
  • listPendingInvitationsByEmail is declared in lib/repositories/collective-queries.ts and implemented in lib/infrastructure/better-auth-collective-queries.ts, but has zero production callers (only test-mock references). It was scaffolded and never wired.

Options

Either (a) wire CollectivesSection.tsx into routes/orgs.tsx (and/or profile) and populate pendingInvites from listPendingInvitationsByEmail(sessionUser.email) so invitees can see and accept invites in-app, or (b) delete the dead island + query if the server-side auto-claim (#1186) is deemed sufficient and no in-app prompt is wanted.

Note: with #1186's auto-claim, an invited operative now auto-joins on first verified sign-in, so this is a UX/cleanup decision rather than a functional gap.

Found while triaging #1186.

02Bog Flow
✓OPEN○TRIAGED○IN PROGRESS◉CLOSED

Closed

8/12/2026, 3:54:06 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

keeb commented 8/12/2026, 3:54:06 PM

Resolved — closing.

Both halves of this issue are addressed in the current tree, by option (a) (wire it) rather than option (b) (delete it):

  • islands/CollectivesSection.tsx no longer exists. The invitee-facing accept/decline surface it described is now a PendingInvites component, rendered from routes/orgs.tsx:149.
  • listPendingInvitationsByEmail is no longer callerless. routes/orgs.tsx:61 calls it with the session email and maps the result into PendingInviteView[]; lib/app/operative-visibility.ts:217 is a second production consumer.

So a pending invitee does see and can act on their invites in-app, which was the open question. Verified against the working tree on 2026-08-12.

Sign in to post a ripple.