Skip to main content
← Back to list
01Issue
BugShippedSwamp ClubPublic
Assigneeskeeb

Relationships

#1880 Inviter gets no credit when the accepted account email differs from the invited email (plus-addressing mismatch)

Opened by doneilltfin · 8/27/2026· Shipped 8/28/2026

Sending an invite via the API and then accepting it from a different account leaves the inviter uncredited.

Repro

  1. As personal account sntxrr, create an invite via the API:

    curl -X POST https://swamp-club.com/api/v1/invites \
  -H "x-api-key: $SWAMP_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"email\":\"<work-local>@<work-domain>\"}"

  2. In work account doneilltfin, accept the invite — but the account/invite that was accepted is under the plus-tagged variant <work-local>+<tag>@<work-domain>, not the bare <work-local>@<work-domain> that was invited.

Observed

  • The invite is accepted and the work account is onboarded.
  • sntxrr (the inviter) receives no credit for the invite.

Expected

  • The inviter is credited when the invite they sent is accepted.

Likely cause

The invited email (<work-local>@<work-domain>) and the accepting account email (<work-local>+<tag>@<work-domain>) differ, so the pending-invite lookup at claim time does not match and the attribution/binding never happens. This is the exact-match email lookup asymmetry described in #1812 (invite repo findOne({ email }) vs the lowercasing claim path) — plus-addressing is another normalisation the read edge does not account for.

Suggested fix

  • Normalise emails consistently at the invite/claim boundary, and decide policy on plus-addressing (canonicalise local+tag@domain to local@domain for invite matching, or match on both) so the accepting account binds to the pending invite and the inviter is credited.
  • #1812 — identifier lookups are exact-match/case-sensitive (same read-edge normalisation gap)
  • #1810 — invite claim gating (adjacent claim-path failure mode)
  • #1653 — inviter is never told when an invite mis-lands (this is a concrete mis-land)

Work email redacted; API key was passed via env var, not a literal.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 2 MORETRIAGE+ 9 MOREREVIEW+ 6 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/28/2026, 12:53:00 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
keeb assigned keeb8/27/2026, 10:48:17 PM
Editable. Press Enter to edit.

keeb commented 8/28/2026, 12:53:04 AM

Thanks @doneilltfin for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

keeb commented 8/28/2026, 12:55:23 AM

Follow-up: the binding half is fixed and verified in prod (invite accepted, inviteeId set, 2026-08-28T00:51:16Z), but the inviter still shows no credit on the Genesis surface.

Filed #1884 for the second, independent defect: recruit_first ("New Blood") resolves to invitesLanded, which is eventTotal("collective_invite_landed") only — an event the platform lane never emits. So a platform invite could not complete that challenge even once bound, and would not have completed it after the tier-gated payout either.

Both defects had to be present for the inviter to see nothing, which is why fixing this issue alone did not clear the box.

Sign in to post a ripple.