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

Relationships

#2210 A pending platform invite that loses to the recruit lane is never consumed and leaks a pending slot

Opened by skunk-ape · 9/16/2026

Problem

Since #2179, when someone arrives through a recruit link and also has a pending platform invite to their address, the recruit lane wins and the invite's ADDRESS arm yields. That is the intended precedence — one human, one credit — but the losing invite is left status: "pending" forever. Nothing ever consumes or expires it.

MAX_PENDING_INVITES_PER_OPERATIVE is 20, counted by countPendingByInviter over pending status (lib/domain/platform-invite/platform-invite.ts, mongo-platform-invite-repository.ts). So every invite that loses this way permanently occupies one of that operative's twenty slots, with no surface to clear it.

The perverse part: the better an operative's recruit link converts people they had also emailed, the closer they creep to being unable to send invites at all.

Scale

Not urgent at current volumes — it needs an operative who both emails invites and shares their link, and it burns one slot per overlap. But it is monotonic and there is no recovery path short of editing Mongo.

Possible fixes

  • An expiry on pending platform invites (they already carry createdAt and lastSentAt), which would also bound the more general case of invites nobody ever accepts.
  • Or a reconcile pass that marks an invite superseded once its address belongs to an account already bound on another lane.
  • Or exclude superseded invites from countPendingByInviter specifically, which fixes the leak without changing invite lifecycle semantics.

The first is probably the most useful independent of this bug.

Surfaced by the adversarial review on #2179 (ADV-20) and recorded there as a known consequence rather than solved in that change.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

9/16/2026, 9:26:53 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.