Skip to content

room-share: a join drops the notice entirely when the roster pushes the envelope over 4,000 units #1932

Closed

Description

@HugoXK

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 3de267c5d3ce4ca6b67dbfc09ed4db8a
Branch: dev/1-fitjoin-notice
Base: 77c9bc6
At: 2026-10-31T12:26:44Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What. fitJoin in core/src/shared/room-share.js trims the notice before the roster, and it trims it by the envelope's total overflow (extra = wire().length - ROOM_SHARE_TEXT_MAX) instead of by the notice's own contribution. When the overflow comes from the roster, extra is far larger than the notice, so the notice is deleted outright — and the roster is popped afterwards anyway, so the deletion buys nothing.

Why it matters (user-visible). On the receiving side a join with notice present sets or clears the notice, and absent leaves it untouched (core/src/host/room-membership.js, noticeOf). So in any room whose roster pushes the envelope near 4,000 units, the guest never receives a notice update and never receives an explicit clear: the room keeps showing the old notice with no hint that anything was dropped.

Reproduction (live main 77c9bc66, pure encode→parse, no network). Roster rows are { name: 'Coder NN', handle: '@coderNN', home: '@hN.test', ownerName: 'O'.repeat(60) }:

roster rows notice wire parsed notice roster out
28 '' 3923 '' (kept) 28
28 'x' 3924 'x' (kept) 28
29 '' 3911 ABSENT 28
29 'x' 3911 ABSENT 28
30–32 '' / 'x' 3911 ABSENT 28

An explicit empty notice — 0 characters of payload — is deleted, and the notice's own length has no bearing on the outcome.

Expected.

  • The notice is trimmed only by its own contribution, and survives whenever it still fits after the roster is fitted.
  • notice: '' is preserved (present and empty means "clear") and never dropped for space it does not use.
  • Roster rows are display data: fit them by their own cost before deleting the notice.
  • The envelope stays ≤ 4,000 units.

Acceptance (red first, assert on the parsed fields).

  1. 29-row roster as above + notice: 'x' → parses back to 'x', wire ≤ 4000.
  2. Same roster + notice: '' → parses back to '' (present and empty).
  3. 26-row roster + 2000-character notice → still trimmed to ≤ 4000, and well formed (no half code point).
  4. Mutation: revert the fix → 1 and 2 go red.

Scope. fitJoin in core/src/shared/room-share.js (about 6 lines) + one case in core/test/remote-room.test.js + the mirror patches/ds-bot/files/src/shared/room-share.js. This is not introduced by #1929 (fitJoin was untouched there); it is existing behaviour.

Not in this change. The fitTransport text loop and the code-point cut work from #1929 are already on main; do not re-touch them.

Dedupe: checked open issues — #1928 (body/history cut, closed by #1929) and #1930 (host prompt cuts) are the nearest; no open issue covers notice preservation in fitJoin.

Activity

  1. HugoXK commented on Oct 31, 2026

    @HugoXK
    ContributorAuthor

    Heartbeat

    Written-by: FlyBot Lead
    Still-working: 3de267c5d3ce4ca6b67dbfc09ed4db8a
    At: 2026-10-31T12:37:27Z

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions