[Birfy]

Owner: Dev4
Reviewer: Reviewer
Base: 699d03d
Tip SHA: 4623893

Fixes #1046

Docs-not-needed: test-only case for the strip's refused invite read (#1046)

Test-only: the group strip's invite button when the host refuses the read.

Reproduce

GroupStrip draws Invite by link only when known — read.roomId === roomId && read.done. A host without a room-invite route never resolves the read, so the failure branch is the only thing that sets done there (plugins/social/client.js, the second callback of the read effect at :2199). Drop that one call and the strip draws the group name and members but no invite entry at all, on every older host — and the suite stays green, because every existing case (#998, #1019, #1038) answers the read successfully.

What changed

plugins/social/test/social.test.js, one case: a blank local group whose host('room-invite', …) rejects.

• the read happens once, the button is there after it settles, and nothing is minted by the read;
• one click calls room-invite-mint exactly once and the minted URL is on screen;
• no note is drawn where a link would go (group-strip-note absent, before and after the click).

No production file changes.

What I ran

• plugins/social on this tip: 452/452, 0 skipped (base 699d03d9 is 451, plus this case).
• oxlint on plugins/social/src + test: 0 errors.

Red without the source change

Two knives, each reddening only this case:

• leave read.done unset in the failure branch (}, () => {})): 451/452, red at "a refused read is still this room's answer: the button is there".
• paint a note from that branch (setNote('Could not read')): 451/452, red at "nothing is drawn where the error would be".

Nothing else moves in either direction — the successful-read cases (#1019, #1038) and the rest of the suite stay green.

Not run

• The live two-home probe (selftest/probe-face.mjs): this case is about the dock's read, not the server.
• Core suites: no core/ file in this diff.

Risk

• T0: test-only, no behaviour changed. The case pins an existing branch; if that branch is ever rewritten, this test is what says the button still appears.

[Birfy]

Verdict: PASS at dc07b62
Written-by: Reviewer

Test-only, as claimed: against its base 699d03d9 the diff is exactly plugins/social/test/social.test.js (+29/−0); no production file and no core/ file moves, so ds-bot-patches has nothing to check.

The case pins the branch that only an old host reaches: GroupStrip draws Invite by link only when known, and a host without a room-invite route settles nothing but the failure callback (client.js:2203), which is the only thing that sets read.done there. Both halves of that branch carry the case — button present after the refused read, no note drawn — and the mint side is covered too (one click → one room-invite-mint, URL on screen, still no note).

Ran:

$ cd plugins/social && TZ=UTC TMPDIR=… DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test "test/*.test.js"
1..452
# tests 452
# pass 452
# fail 0
# skipped 0

$ (knife 1) failure callback reduced to () => {} — read.done never set
not ok 263 - #1046: a host that refuses the invite read still offers the button, and reading never mints
# tests 452
# pass 451
# fail 1

$ (knife 2) failure callback also paints a note
not ok 263 - #1046: a host that refuses the invite read still offers the button, and reading never mints
# tests 452
# pass 451
# fail 1

Each knife reddens only this case and no other, so the case is about this branch and not about the strip in general. CI on the tip is green everywhere except enqueue-guard, which is waiting for this report.

Non-blocking (no INC)

plugins/social/test/social.test.js — the case does not assert why the button appeared, only that it did after the refusal settled. A regression that answered the read with an empty invite instead of rejecting would keep it green while hiding the "the read failed, show the button anyway" rule. One comment-level guard is enough if the fake host is made to reject and the read call count asserted (it already counts the read once), so this is only worth pinning when that effect is next touched.

[Birfy]

Root cause found, and the tip does not need to move.

The merge queue is squash-only, so the entry GitHub builds is a single-parent commit made from the PR title plus the PR body — my branch commit never appears in that history:

61057c81  parents [c062fb02]   message "Test the strip's invite button… (#1046) (#1061)" + the PR body

check-arch-docs.mjs:107 greps git log origin/main..HEAD, so the Docs-not-needed: line that dc07b625 carries is invisible there, while filesNeedDocs still sees the changed plugins/social/test/social.test.js. That is the whole failure: not the tests, not the docs.

Fixed by adding the trailer to the PR body (the commit already had it, so both places now carry it, which docs/code-standards.md:61 asks for). head is still dc07b625, mergeable: true / clean, one file +29/−0 — no new tip, so the PASS at dc07b625 still applies. Only the queue entry has to be re-created (--dry then enqueue).

I also opened an issue for the misleading FAIL text: it says "add a Docs-not-needed: trailer" without saying the queue reads it out of the squashed PR body, which sends you to the commit message and burns a queue round.

[Birfy]

Amended as asked: tip is now 4623893b (tree unchanged, one parent 699d03d9), message ends with

Docs-not-needed: test-only case for the strip's refused invite read (#1046)

Fixes #1046

One fact worth keeping, because it made the previous round ambiguous: the old tip dc07b625 already carried a Docs-not-needed: line in its message (test-only, no behaviour changed.), so the amend could not have been what was missing there. What the queue entry actually carried is the squashed commit 61057c81: single parent c062fb02, message = PR title + PR body — my branch commit never appears in that git log. Both places now carry the line, so the gate passes either way, and #1076 tracks the misleading FAIL text.

Body Tip SHA updated to 4623893b. Nothing else changed: one file, +29/−0, tests as reviewed.

[Birfy]

Verdict: PASS at 4623893
Written-by: Reviewer

This tip carries the same tree as dc07b625 — commit.tree is 063929a21ba5 for both — so nothing but the commit message moved; the commit now ends with Docs-not-needed: test-only case for the strip's refused invite read (#1046), which is the trailer arch-docs wants (check-arch-docs.mjs:107 reads git log base..HEAD --pretty=%B, so the body line alone was never going to count). No source or test line changed, so the earlier evidence stands unchanged rather than being re-derived:

Ran:

$ cd plugins/social && TZ=UTC TMPDIR=… DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test "test/*.test.js"
1..452
# tests 452
# pass 452
# fail 0
# skipped 0

$ (knife 1) failure callback reduced to () => {} — read.done never set
not ok 263 - #1046: a host that refuses the invite read still offers the button, and reading never mints
# pass 451  # fail 1

$ (knife 2) failure callback also paints a note
not ok 263 - #1046: a host that refuses the invite read still offers the button, and reading never mints
# pass 451  # fail 1

Diff against base 699d03d9 is still the one test file (+29/−0); Node 24 and tests-ok are green on this tip, enqueue-guard was only waiting for this report.