fix: process join requests from already-consented DMs

[yewreeka]

Problem

Join requests travel over a joiner→creator XMTP DM. When the creator processes a request, it sets that DM's consent to Allowed — but both the batch and catchup scans in process-join-requests only listed DMs with Unknown consent:

const dms = await client.conversations.list({
  conversationType: ConversationType.Dm,
  consentStates: [ConsentState.Unknown],
});

So the first join from a given identity works (new DM, Unknown consent), but any later join request from the same joiner — e.g. joining a second conversation from the same creator — rides the existing, now-Allowed DM and is silently dropped. The joiner is never added and never receives an InviteJoinError, which on mobile clients shows up as being stuck on the "Verifying" screen forever.

(iOS's creator-side InviteCoordinator.processJoinRequestOutcomes already scans [.unknown, .allowed]; this brings the CLI in line. The Android app appears to have the same Unknown-only bug — tracked separately.)

Fix

• Include ConsentState.Allowed in both the batch and catchup DM scans.
• Skip requests whose sender is already a member of the target conversation. Previously the consent flip itself was the implicit dedup that kept batch runs from re-processing old requests; with Allowed DMs in scope, the membership check makes re-scans idempotent.

Denied DMs remain excluded, so blocked spam stays blocked.

Verification

Reproduced on production with a real device:

1. Device joins CLI-created convo Add "popup" subdomain prefix to invite URLs #1 → new DM (Unknown) → processed, added in seconds.
2. Same device joins convo feat: add agent serve command for long-running bot sessions #2 from the same creator → request lands on the existing Allowed DM → process-join-requests returns processed 0 (the bug; device hangs on "Verifying").
3. With this patch: the stale convo-Add "popup" subdomain prefix to invite URLs #1 request logs already a member — skipping, the pending convo-feat: add agent serve command for long-running bot sessions #2 request logs Adding <inbox> to conversation <id>, processed 1, and the device's membership was confirmed via conversation members.

pnpm test: 487 passed. pnpm build (tsc): clean.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

Note

Fix join request processing to handle already-consented DMs

• Adds a member check before adding a sender to a conversation in process-join-requests.ts; skips and logs if the sender is already a member instead of attempting a re-add.
• Expands DM consent state filtering from Unknown only to [Unknown, Allowed] in both the batch DM scan and the catchUp method, so already-consented DMs are also scanned for join requests.

^{Macroscope summarized 91b4a4e.}

[macroscopeapp]

Approvability

Verdict: Approved

This bug fix expands DM scanning to include already-consented conversations so repeat join requests aren't silently dropped. The added idempotency check ensures existing members won't be re-added. Changes are well-scoped with clear defensive logic.

^{You can customize Macroscope's approvability policy. Learn more.}