Skip to content

Add chat members in one batch before single adds - #1602

Closed
baxen wants to merge 1 commit into
mbot/chat-link-sharing-wordingfrom
mbot/batch-chat-access
Closed

baxen wants to merge 1 commit into
mbot/chat-link-sharing-wordingfrom
mbot/batch-chat-access

Conversation

@baxen

@baxen baxen commented Oct 24, 2026

Copy link
Copy Markdown
Collaborator

Stacked on #1591, which is stacked on #1529. Relay side: block/buzz#8575.

What changes

Sharing a chat used to send one kind 9000 per person and read the roster after each one. grantSoloChatAccess now:

  1. Sends one kind 9000 naming every fresh person. Agents carry bot as the p tag's third element.
  2. Reads the roster once.
  3. Gives anyone the roster doesn't show today's single add, which also reports that person's own failure.

It does this only when two or more people are fresh. A fresh person is valid, not already a member, not archived, has no addition already under way, and is not an agent being added where single adds would refuse agents.

Works on today's relays

A relay without #8575 adds only the first p, and reads the role only from the event's role tag. So:

  • Humans go first and a mixed batch carries no event-wide role, so that first person is added as a plain member.
  • A batch of only agents also carries ["role", "bot"].
  • The client trusts the roster rather than the OK message, so everyone the old relay skipped falls back to single adds.

Failure handling (from agent review)

  • Best effort: a failed outbox, roster read or send leaves everyone to the single path rather than failing the share. Only an abort, or a stop from beforeDispatch, ends it.
  • Receipts:
    • Each batch has its own recovery key (member-add:batch:<uuid>).
    • Single adds never resume a batch receipt.
    • A settled batch is acknowledged in Outbox, and so is one left behind by a reload. Neither can block later additions.

Tests

share.test.ts:

  • Relay fixture: it now models both relay kinds. By default it adds only the first p; setup({ batch: true }) adds them all.
  • New tests:
    • Everyone is added in one event.
    • A batch of only agents carries the event-wide bot role.
    • Only the people a batch missed are retried, and each reports their own reason.
    • A failed roster read after a batch falls back instead of failing the share.
    • A single add doesn't resume another share's batch that is still in flight.
  • Fail-then-pass: each new test fails with the batch path disabled or the fix reverted, and passes now.
  • Updated: the existing agent test now asserts the old-relay fallback (batch, then a single add with role=bot). Its onConfirmed check now ignores order, since batch order puts humans first.

Validation:

  • Full vitest run at 1ca91f57e: 736 files passed, 0 failed.
  • tsc is clean.
  • Not yet exercised in the app or against a relay running #8575.

🤖 Generated with Claude Code

Sharing a chat with a channel sent one kind 9000 per person and read the
roster after each. Send one kind 9000 naming every fresh person instead,
with per-person roles in the p tags, then read the roster once.

A relay without batch support adds only the first p and reads only the
event's role tag, so humans go first and an all-agent batch also carries
role=bot. Whoever the roster doesn't show falls back to today's single
add, which reports that person's own failure.

The batch is best effort: a failed read or send leaves everyone to the
single path rather than failing the share. Each batch has its own
receipt key, single adds never resume a batch receipt, and a settled or
left-over batch is acknowledged so it can't block later additions.

Relay side: block/buzz#8575.

Co-authored-by: mbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Bradley Axen <baxen@squareup.com>
@baxen baxen closed this Oct 24, 2026
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