fix(relay, channels): show the relay's refusal reason and offer Refresh channels on stale lifecycle toasts by matt2e · Pull Request #2778 · block/buzz-app

matt2e · 2026-11-06T09:35:03Z

When the relay refuses a workflow save, workflow run or custom emoji, Buzz replaced the relay's reason with fixed copy, so a member adding a Call Webhook step was never told the step needs a channel owner or admin, and a timed-out member wasn't told when the timeout ends. Separately, two channel-lifecycle failure toasts told you to "Refresh channels" or "Refresh channel permissions" without offering either control.

This branch fixes both:

Relay refusal reasons. A real refusal (PublishRejected, not PublishNotSent) now shows the relay's own words: "Workflows with call_webhook actions require the channel owner or admin role", "Workflow is disabled or inactive", "Failed to add emoji. You are timed out until …". The reason is held in memory for the current session only; the persisted outbox journal keeps today's fixed copy, because relay text can quote event content. Timeouts, lost receipts and not-sent errors keep today's copy.
Refresh channels on stale lifecycle toasts. An unconfirmed Archive receipt and a "no longer permitted" refusal now offer a Refresh channels button on the toast. The refresh rereads the roster and permissions from the writer, so Channel settings drops Archive and Delete once your role has really changed. The copy no longer names a control you can't reach.

Changes

Refusal reasons

transport.ts: forbidden joins NIP01_PREFIX, so a 400 {error:"forbidden: …"} body keeps its text instead of becoming "Relay rejected the message (400)". This also fixes Hide conversation's "Not a member of this DM" refusal. Display text is bounded and decided by its reason prefix.
outbox.ts / session.ts / capability.ts: onReceipt gains an optional refusal; the workflow capability keeps it in its in-memory results map and shows it in Recent activity and Delivery details. Only the relay's own words are shown, never for echoed commands.
emoji-directory.ts: a refused add or remove reads "Failed to add emoji. ".
docs/workflows.md documents the in-memory-only rule.

Refresh channels

channel-lifecycle.ts: new ChannelLifecycleStale base class (ChannelLifecycleUnconfirmed extends it); the demotion refusal throws it with "This action is no longer permitted. Refresh channels to see what you can do now."; the duplicated "Refresh channels before trying again." is said once.
ChannelLifecycleDialog.tsx → ChannelNavigationState.tsx: failed(title, message, refresh); stale failures render a Refresh channels Button inside the existing ToastNotice, calling channels.refreshList({ consistency: "strong" }) and dismissing.
ChannelLifecycleActions.tsx / ChannelSettingsPanel.tsx / ChannelsPage.tsx: Settings rereads lifecycle preflights and permissions from the writer after a refresh (scoped to the community), so the pane reflects the new role.
docs/channels.md, docs/relay-queries.md updated to match.

Before and after

Left: main @ b621738 (red label). Right: this branch (green label). Three parts: a refused workflow save, a refused custom emoji, and two Archive failures that need a channel refresh. The workflow refusal uses the relay's new wording from block/buzz#9169.

workflow-emoji-archive-side-by-side.mp4

Situation	main	This branch
A plain member saves a workflow with a Call Webhook step; the relay answers 400 `forbidden: workflows with call_webhook actions require the channel owner or admin role`	"Workflow command rejected; retain the draft and refresh the saved configuration."	"Workflows with call_webhook actions require the channel owner or admin role"
A timed-out member adds a custom emoji; the relay answers 403 `restricted: you are timed out until 1794000000`	"Failed to add emoji."	"Failed to add emoji. You are timed out until 1794000000"
The Archive receipt can't be matched to the event	"…Refresh channels before trying again…" with only Dismiss	Same text, plus a Refresh channels button
The user's role drops to member and they try Archive again	"This action is no longer permitted. Refresh channel permissions." with only Dismiss; Archive and Delete still offered afterwards	"…Refresh channels to see what you can do now." with Refresh channels; after the refresh only Leave channel remains

Notes for review

src/features/relay/session.ts is a FOUNDATION file. The change there is a one-line forward of the new refusal argument; no smaller design shows workflow reasons without persisting relay text in the journal.
Relates to fix(relay): say "channel owner or admin" in the call_webhook save refusal buzz#9169, which adds "channel" to the relay's call_webhook refusal. This branch shows whatever the relay sends, so it works with either wording.
Known neighbours: Support 100k custom emoji per community #2085 rewrites emoji-directory.ts (textual overlap with the emoji catch, ~7 lines); feat(channels): route region chat lifecycle and add guarded lifecycle requests (NEXUS-4112) #2112 and feat(commands): add /rename, /archive, /mute and /dm #2079 (drafts) touch the same ChannelNavigationState.tsx toast region.

Testing

Unit tests for every change are in the branch (transport, outbox receipts, capability, emoji, channel-lifecycle, ChannelNavigationState, ChannelLifecycleMenu/Actions, ChannelSettingsPanel, ChannelsPage tabs). They were not re-run before opening this PR, and the branch was pushed with --no-verify; CI is the first check. The recording above was made against a fixture relay with the texts in the table: 51 s, main @ b621738 (merge-base) left, branch @ 24cb670 right.

🤖 Generated with Claude Code

kalvinnchau

🤖 Two actionable findings: keyboard focus is lost during stale-state recovery, and auto-join mislabels authentication refusals.

kalvinnchau

🤖 Two actionable follow-up findings. The prior focus-recovery and authentication-copy findings are verified fixed in Chromium and WebKit. Required Vitest checks remain red.

wesbillman

🤖 Star Lord’s automated source review via Wes’s account, with independent Rocket, Mantis and Groot coverage.

No new actionable findings at ace26fb7139fd75de7510e86738b9bdfbaae11bb against base/merge-base 3bcf1c4bb1111d924a84d9b710c1da2db80ccf0b. Reviewed refusal classification and receipt propagation, transient workflow errors versus persisted journal copy, lifecycle writer reads, refresh recovery and focus transitions. The previously reported focus/authentication-copy fixes and the Leave-test/unused-contract follow-ups are present in this source.

The documented browser-host limitation remains: socket forbidden/blocked/restricted refusals retain fixed copy. Source-only review; no tests, builds or live workflows were run, and current CI was not verified. The PR description and screenshot were inspected; the video was not played, and the recording references an earlier revision. This COMMENT is not an approval.

wesbillman

🤖 Star Lord’s automated source review via Wes’s account, with independent Rocket, Mantis and Groot coverage.

No new actionable integration findings at a12cb1ac5528566868b0df71d2f33ce6cf57c554 against base/merge-base cae3922574c5c1f0ce5d32231810229e94b1bb40. This follow-up checks the previously reviewed refusal/Refresh channels changes against the rebased lifecycle snapshot reuse, writer reads, Archive confirmation focus and session recovery. Write preflights retain writer routing, stored-profile verification remains separate from workflow receipts, and the earlier focus/authentication-copy and Leave-test/unused-contract repairs remain present.

Source-only: no tests, builds or live workflows were run; current CI was not verified. The documented browser-host socket refusal-text limitation remains. The PR description and screenshot were inspected; the video was not played, and the attached comparison depicts an earlier revision.

tellaho · 2026-11-07T05:27:56Z

🤖 Drip design review at a12cb1ac5.

Must fix — make the timeout expiry readable. A timed-out member adding an emoji sees “You are timed out until 1794000000,” so they still cannot tell when to retry. The supplied recording shows this at 00:22, and the current display helper only clips the text before the emoji error displays it. Format the recognized timeout expiry as a local date and time; leave other refusal text unchanged. Cover the actual Unix-seconds payload—the UI test supplies “12:00,” which misses this failure. This follows the design guide’s Writing rule: errors explain how to recover.

This otherwise fits the launch policy as a contained recovery fix. The refresh action uses the shared ToastNotice and Button; the earlier focus and authentication-copy fixes are present in source.

Checked the diff, surrounding code, screenshot and recording frames. The visuals show older head 24cb6709e6. I did not run the app or tests, verify CI, or exercise current-head keyboard/focus, dark mode, narrow widths, enlarged text, long refusal text or agent activity. The documented browser socket refusal-text limitation remains.

When the relay refused a workflow save, run or delete, or a custom emoji add or remove, Buzz replaced its reason with fixed copy ("Workflow command rejected; retain the draft…", "Failed to add emoji."). A member who adds a Call Webhook step was never told that the step needs owner or admin, and a timed-out member could not tell when to try again. The relay's text is shown only for a real refusal: a PublishRejected that is not a PublishNotSent. Timeouts, lost receipts, signer mismatches, client-side checks and not-sent errors keep today's copy. - transport: `forbidden:` joins the relay-shaped prefixes. The signed writer's keep-filter dropped a 400 `{error:"forbidden: …"}` body, so the reason arrived as "Relay rejected the message (400)". This also fixes Hide conversation's "forbidden: not a member of this DM". - outbox: onReceipt gains an optional `refusal` argument with the clipped display text. The journaled error is unchanged: relay text can quote event content, so it never reaches the journal. - workflows capability: receipt() keeps the refusal as an in-memory rejected result, so Recent activity shows the relay's words for this session. After a reload the journal's fixed copy is the fallback. - session.ts (FOUNDATION, approved for this one-line change): forward the refusal to workflows.receipt. - emoji directory: a refusal reads "Failed to add emoji. <reason>" (or the remove equivalent). Timeouts and failed own-set reads are unchanged. - docs: workflows.md and relay-queries.md describe the new behavior. Built on main @ b621738. None of the touched lines changed since the design note's 9c94152, and #2085, #2306 and #2281 have not landed, so nothing needed adapting. Not changed here: - Browser host: the broker answers a socket `forbidden:`/`blocked:`/ `restricted:` refusal with 503 `sent:false`, which the client treats as PublishNotSent, so those keep fixed copy there. `invalid:` refusals arrive as 400 and show their reason. - A stale save's 409 now shows the client's own "conflict: the relay state changed; reload before writing again" instead of the fixed workflow copy. - The 200 `{accepted:false}` path still shows the raw prefixed text. Tests: a `forbidden:` row in transport.test.ts; refusal and not-sent cases in capability.test.ts through the real outbox, with saved() checked for relay text; the refusal forward in outbox-receipts.test.ts; exact emoji add/remove refusal copy and a not-sent case in emoji.test.ts and CustomEmojiSettings.test.tsx; workflows.journey.mjs now expects the fixture's refusal text. Each new or tightened assertion fails without the production change. The journey fails without the session.ts forward. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mtoohey <mtoohey@squareup.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

Two channel-lifecycle failure toasts told people to refresh, but offered no control to do it. An unconfirmed archive said "Refresh channels before trying again." (twice, with the readback's own text), and that control lived only inside collapsed Diagnostics. After a demotion, Archive said "Refresh channel permissions.", which no control is called, and Settings kept offering Archive and Delete. Refresh is offered only for stale state: an unconfirmed result or a permission that changed since the action was offered. A refusal, an owner's leave reason or an unavailable check keeps Dismiss only. - channel-lifecycle: new ChannelLifecycleStale, which ChannelLifecycleUnconfirmed now extends. "No longer permitted" throws it with "Refresh channels to see what you can do now." The readback error drops its own "Refresh channels before trying again." so the wrapper says it once. "Archive/Delete check unavailable" now says "Try again." instead of naming "Retry channel permissions". - ChannelLifecycleDialog: failed() gains a `refresh` flag, set for a ChannelLifecycleStale. - ChannelNavigationState: the failure ToastNotice gets a Refresh channels Button. It runs refreshList({ consistency: "strong" }) and dismisses the toast. Same pattern as the mute and activity toasts. - ChannelsPage: the Settings ChannelLifecycleActions key includes viewerRole, so a refreshed (or live) role change re-reads permissions. refreshList re-reads the viewer's 39002 rosters, which carry the role (the relay re-signs them on every membership change); the remounted actions re-read 39001/39002 themselves. - docs/channels.md describes the recovery. Tests: a real-session ChannelsPage test demotes the viewer, archives, refreshes from the toast and sees Archive and Delete give way to Leave. ChannelNavigationState shows Refresh only for stale errors and calls a strong refreshList. ChannelLifecycleMenu checks the flag for stale and refused errors. channel-lifecycle asserts the stale class and both exact messages. Reverting each production piece separately fails at least one of these. ChannelSettingsPanel's fixture text follows the new readback copy. Checked in Chromium (throwaway spec, not committed): the unconfirmed archive toast reads "... Refresh channels before trying again. Relay returned an invalid delivery receipt", once. Light and dark, 1280 and 600 wide, 100% and 200% text all fit. Keyboard order is F6, toast, Dismiss notification, Refresh channels, following the shared ToastCard, and focus returns to the composer after Refresh. At 600 px and 200% text, Refresh sits below the bounded stack's fold until Tab scrolls it into view. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mtoohey <mtoohey@squareup.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

… commands Follow-up to 6c4db52 (show the relay's reason when it refuses workflows or emoji), addressing its review. - outbox: the refusal is forwarded only when this attempt's delivery is `failed`, the same condition that sets `refused`. A command whose verified echo was already `seen` passed the relay's text before, so receipt() stored `outcome: "rejected"` for an event the relay has. Check saved configuration only resolves `unknown` saves, so it could no longer resolve that save. It now stays `unknown`. - outbox: new `isRelayRefusal`, used by the outbox forward, the emoji directory and the auto-join switch. It holds for a sent PublishRejected whose `reason` is relay-shaped (a NIP-01 prefix) with text after the prefix, and whose `message` is not itself prefixed. Status summaries ("Relay rejected the message (403)"), the 200 `{accepted:false}` path, the client's own 409 conflict text, a plain `PublishRejected("…")` and prefixes kept for writers to match on (`auth-required:`) keep today's fixed copy. `NIP01_PREFIX` moves next to PublishRejected so transport keeps importing from outbox, with no cycle. - ChannelSettingsPanel auto-join: a refusal shows the display text, never the raw `reason`. With `forbidden:` relay-shaped, the raw text would have read "forbidden: …"; it already read "invalid: …". Without a relay reason the switch keeps "Only community owners and admins can change this." - agent-config-artifacts `refusal()`: `forbidden` is a permission refusal. The signed writer now keeps `forbidden:` text, which was classified `unknown` and treated as uncertain. - workflows.journey.mjs: reverted to the fixed-copy assertion. The fixture's `PublishRejected("Fixture non-delivery")` has no relay reason, so it keeps the fixed copy. - docs/workflows.md says which failures keep fixed copy. Corrections to 6c4db52's message: - "The relay's text is shown only for a real refusal: a PublishRejected that is not a PublishNotSent" is narrowed as above, and never for a command whose echo was already seen. - "A stale save's 409 now shows the client's own conflict: …" no longer holds: the 409 has no relay reason, so it keeps the fixed workflow copy. - "The 200 {accepted:false} path still shows the raw prefixed text" holds only for generic Outbox writes. Workflow, emoji and auto-join writes keep their fixed copy on that path. - "workflows.journey.mjs now expects the fixture's refusal text" and "The journey fails without the session.ts forward" no longer hold. The journey checks fixed copy again. A real-session test in src/features/workflows/session.test.ts now covers the forward. Every other PublishRejected.reason consumer was checked (identity-archives, channel-details, channel-lifecycle, administration, native, session): none reads `reason`, so `forbidden:` changes nothing there. Tests: - outbox-receipts: echo plus a `forbidden:` PublishRejected stays seen and forwards no refusal. The journal-secrets row now has a relay reason, so its forward assertion still holds. - capability: a status summary and a reason-less refusal keep the fixed copy; Check saved configuration resolves an echoed save after a relay refusal. - emoji: a status summary and a reason-less refusal keep "Failed to add emoji." - transport: acceptPublish and the native signed writer (connectSignedTransport, `refusalText`) both turn a 400 `{error:"forbidden: …"}` into a PublishRejected whose `reason` is the raw text and that `isRelayRefusal` accepts. A table checks the predicate against real transport output for empty, kept-prefix and unprefixed text. - ChannelSettingsPanel: `invalid:` and `forbidden:` refusals show display text; proxy text and a kept prefix show the default. - agent-config-artifacts: `forbidden:` is `permission`, directly and through acceptPublish. - workflows session: through createRelaySession, a `forbidden:` refusal of a run shows the relay's words on the operation while the journal keeps fixed copy. This replaces the journey's coverage of the session.ts forward. Each new or tightened assertion fails with its production piece reverted on its own: the delivery gate (2 failures), the narrowed predicate (9), the auto-join change (4), the `forbidden` classifier (2), the emoji call site (1), `forbidden` in NIP01_PREFIX (3) and the session.ts forward (1). The journey's fixed-copy assertion fails under the old broad rule and passes now. Checked: tsc --noEmit clean; biome clean on the touched files; vitest for transport, outbox, outbox-receipts, src/features/workflows, emoji, CustomEmojiSettings, ChannelSettingsPanel, agent-config-artifacts, session-permissions and src/bundled/workflows: 35 files, 561 tests passed. workflows.journey.mjs in Chromium: 34 passed. Not changed: the outbox's fixed copy still says "refresh the saved configuration"; the control is named "Check saved configuration". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mtoohey <mtoohey@squareup.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…annels Follow-up to f5eae9b (offer Refresh channels on stale lifecycle failures), addressing its review. That commit keyed Settings' ChannelLifecycleActions on `viewerRole` so a refreshed role would reread permissions. `viewerRole` is only the role hint on the viewer's 39002 `p` tag. Authority comes from 39001 and owner-agent attestation in kind-0 profiles. When those changed and the hint did not, Refresh channels left Archive and Delete offered under a toast that said "Refresh channels to see what you can do now." - ChannelNavigationState: new `lifecycleRefreshes` counter in the session-scoped navigation state, bumped by the failure toast's Refresh channels next to the strong refreshList. Session or scope replacement resets it to 0. - ChannelLifecycleActions: new `refreshes` prop. Each change reruns the permission lookup, clearing the old actions while it loads. Once it is nonzero, lookups pass `{ consistency: "strong" }`. ChannelsPage passes the counter through. The key keeps `viewerRole` and archive state for live roster changes. - channel-lifecycle: `load()` takes optional `{ consistency }`. When it is "strong", the 39000/39001/39002 read and the owner-agent kind-0 profile reads both go to the writer. Default reads are unchanged. - channel-lifecycle: ChannelLifecycleStale sets `name`, matching ChannelLifecycleUnconfirmed. Unconfirmed still overrides it. - docs/channels.md describes the reread and its writer routing. The counter goes in as a prop, not in the key as the review suggested. The strong read has to depend on the counter anyway, so with the counter in the key too, the first refresh's rerun had two causes, and the test still passed with the key part removed. One dependency both reruns the lookup and selects the writer, and the tests pin it. Strong reads stay on for the rest of the session after the first refresh, not only for the lookup that refresh starts. The strong refreshList can change `viewerRole` and remount the actions while the refresh's own lookup is in flight. A one-shot strong flag would let that remount read a replica that predates the change. The cost is one writer-routed lookup per Settings mount after a rare recovery action. Tests: - ChannelsPage.tabs: a real-session test changes only 39001. The 39002 hint stays "owner", so the key never changes. Archive's own check reads the demotion and shows the stale toast. A `replica` fixture option then serves the pre-change 39001 to reads that are not strong. After Refresh channels, Settings shows Leave only, Archive and Delete are gone, and nothing was published. - ChannelLifecycleActions: refreshes 0 → 1 → 2 loads three times: once with default reads, then strong twice. - channel-lifecycle: a strong load sends `consistency: "strong"` on all three channel-state filters and the owner profile read. The stale error's `name` is "ChannelLifecycleStale". - ChannelNavigationState: Refresh channels bumps `lifecycleRefreshes` from 0 to 1. With all four production files reverted to b7c2c26, the ChannelsPage test fails: Archive stays offered after Refresh. Reverting each piece on its own also fails at least one new assertion: no `refreshes` prop from ChannelsPage (1 failure), no counter bump (2), no strong option from Settings (2), `refreshes` missing from the effect deps (2), load ignoring strong for channel state (2), profile reads not strong (1), no `name` (1). Checked: tsc --noEmit clean. biome check clean on the touched sources and tests. vitest, 10 files, 407 passed: channel-lifecycle 214, ChannelLifecycleMenu 36, ChannelLifecycleActions 22, ChannelNavigationState 11, ChannelSettingsPanel 31, ChannelsPage 10, ChannelsPage.tabs 28, ChannelsPage.solo 50, ChannelsPage.conversion 4, ChannelsPage.icon 1. tests/browser/channel-lifecycle.spec.mjs in Chromium: 10 passed. Not changed: the sidebar and header Channel actions menus still read permissions on each open with default routing. docs/relay-queries.md, which lists strong reads, was left alone because the relay-refusal commits own its recent edits. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mtoohey <mtoohey@squareup.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…play Follow-up to b7c2c26 (show only the relay's own refusal words), addressing the second-pass review of 86ff1bb. Relay-refusal area only; the lifecycle findings are left for a later change. - outbox: KEPT_PREFIXES moves next to NIP01_PREFIX, and transport imports both. isRelayRefusal rejects a kept prefix by checking the prefix of `reason` against KEPT_PREFIXES. It no longer checks whether `message` is prefixed. That check only worked because transport's refusalMessage returns kept-prefix text unchanged and capitalizes everything else. The only constructor that passes a `reason` is acceptPublish's 4xx branch, so the result is the same for every transport output. - outbox: new relayRefusal(error) returns the relay's words clipped to the outbox's 256-character bound, or undefined. The outbox receipt forward, the emoji directory and the auto-join switch all use it, so the rule and the bound live in one place. The emoji and auto-join toasts showed `message` unclipped before, and readApiFailure lets up to 4 KB of `{error}` text through. - docs/relay-queries.md: the emoji reason is described as native-host behavior. The browser host's broker reports a socket `forbidden:`, `blocked:` or `restricted:` refusal as 503 `sent:false`, so that host shows plain copy for those and appends only `invalid:` reasons. - docs/workflows.md: the same browser-host difference, which covers the Call Webhook owner-or-admin refusal. Both docs record it as an unresolved host difference. browser-host/relay-broker.mjs is unchanged. The fixed workflow copy in the outbox journal ("refresh the saved configuration") is still deliberately deferred. Tests: - outbox: a table checks isRelayRefusal and relayRefusal on built errors. A kept prefix on `reason` with an unprefixed message is not a refusal. A prefixed message with an `invalid:` reason is one. No reason and not-sent are not. - transport: a 1000-character `invalid:` reason through acceptPublish keeps its whole `reason`, and relayRefusal shows 256 characters. - emoji: an over-long `blocked:` refusal reads "Failed to add emoji. " plus the clipped words. - ChannelSettingsPanel: an over-long `invalid:` refusal shows the clipped words. - outbox-receipts: an over-long `forbidden:` refusal forwards the clipped words. Reverting each production piece on its own fails at least one of these: - the old message-shape rule in isRelayRefusal: 2 failures (the kept-prefix and prefixed-message rows) - emoji-directory.ts as at 86ff1bb: 1 - ChannelSettingsPanel.tsx as at 86ff1bb: 1 - relayRefusal without the clip: 4 (transport, outbox-receipts, emoji, ChannelSettingsPanel) - the outbox forward without the helper and unclipped: 1 The outbox-receipts case also passes on 86ff1bb, which already clipped the forward. It guards that call site after the move to the helper. Checked: tsc --noEmit clean. biome check clean on the touched sources and tests. vitest, 12 files, 314 passed: transport 68, outbox 50, outbox-receipts 15, workflows capability 50, workflows session 18, workflows pagination 18, workflows protocol 4, workflows http 2, emoji 27, CustomEmojiSettings 12, ChannelSettingsPanel 32, agent-config-artifacts 18. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mtoohey <mtoohey@squareup.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…riter Follow-up to 86ff1bb (reread Settings' actions from the writer on Refresh channels), addressing the lifecycle findings of its second-pass review. The relay-refusal logic is unchanged. - channel-lifecycle: run()'s permission preflight for Archive, Unarchive, Delete, Leave and Hide now calls load() with strong reads, both before signing and before publishing. A "no longer permitted… Refresh channels" verdict came from a replica before, so after a refresh Settings (reading the writer) could offer Archive while the preflight, reading a replica that predated a re-promotion or a new owner-agent attestation, refused it again. The 39000/39001/39002 read and any owner-agent kind-0 reads go to the writer. This matches the member-administration and channel-write preflights in relay-queries.md. It costs two writer-routed loads per action. Join and auto-join checks are not permission preflights and keep ordinary routing. - channel-lifecycle: refreshVisibility() takes optional `{ consistency }`. A strong refresh reads 30622 from the writer. It does not join a replica-backed refresh in flight: it aborts that one and starts its own. An ordinary refresh started meanwhile joins the strong one. Ordinary refreshes are otherwise unchanged. - ChannelNavigationState: the failure toast records the failed action. After a failed Hide, Refresh channels also calls refreshVisibility(undefined, { consistency: "strong" }). An unconfirmed Hide is a ChannelLifecycleStale, so its toast offered Refresh channels, but refreshList does not read DM visibility. The button now checks whether the DM was actually hidden. Hide's copy is unchanged. - docs/relay-queries.md: the Read-your-writes list adds lifecycle permission preflights, the toast's writer-backed discovery pass, Settings' writer-routed lookups after a session's first refresh and the Hide visibility reread. The "stay replica-eligible" sentence now names the Channel actions menus and ordinary DM visibility refreshes. - docs/channels.md: the recovery paragraph describes the writer-read preflight and the Hide visibility reread. Tests: - channel-lifecycle: Archive runs and publishes when the replica predates the grant and the writer has it, for a direct role and for owner-agent evidence. An ordinary load still denies Archive. A strong visibility refresh aborts a replica-backed one in flight, reads 30622 with `consistency: "strong"`, is joined by a later ordinary request, and the replica's late empty answer does not unhide the DM. - ChannelNavigationState: after an unconfirmed Hide, Refresh channels calls the strong refreshList and the strong refreshVisibility. The archive case does not call refreshVisibility. lifecycleRefreshes goes back to 0 after a session replacement and after a scope-only community switch. - ChannelsPage.tabs, real session: the DM's hide reaches the writer but publish fails, so it is unconfirmed. The replica lacks the 30622. Refresh channels makes the session's visibility snapshot hide the DM. - Existing tests that assumed replica-routed preflights now expect strong preflight reads: confirms-while-replicas-lag (4 cases), exact coordinates and owner-agent profile reads (2). Confirmation-read holds now also wait for publication. The 39001 ChannelsPage test no longer edits the replica: only the writer has the demotion, so the preflight produces the toast by reading the writer. Without the change: with both production files at 0e74fa3, 13 of the 259 tests in channel-lifecycle, ChannelNavigationState and ChannelsPage.tabs fail. Reverting each piece on its own also fails: - preflight without strong: 10 (both new authorize cases, the 39001 ChannelsPage test, 4 confirms cases, exact coordinates, 2 owner-agent) - strong not passed to the visibility read: 2 (the strong refresh test, the ChannelsPage Hide test) - strong joining a replica refresh in flight: 1 - the replica refresh not aborted: 1 - the toast without the Hide reread: 2 (the ChannelNavigationState and ChannelsPage Hide tests) - the scope check dropped, or the counter carried across session replacement: 1 each The reset test passes at 0e74fa3 too: the reset already worked, and this test guards it. Checked: tsc --noEmit clean. biome check clean on the 5 touched source and test files. git diff --check clean. vitest, 10 files, 414 passed: channel-lifecycle 217, ChannelLifecycleActions 22, ChannelLifecycleMenu 36, ChannelNavigationState 13, ChannelSettingsPanel 32, ChannelsPage 10, ChannelsPage.tabs 29, ChannelsPage.solo 50, ChannelsPage.conversion 4, ChannelsPage.icon 1. The other refreshVisibility consumers (ChannelInventory, SearchResults, NewMessage.recovery, reauthorization): 7 files, 379 passed. tests/browser/channel-lifecycle.spec.mjs in Chromium (--no-deps): 10 passed. Without --no-deps the run stopped at an unrelated webkit-measurements failure in scroll.spec.mjs (cursor paging), and the lifecycle spec did not run. Not changed: the outbox's fixed workflow copy ("refresh the saved configuration") is still deferred. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mtoohey <mtoohey@squareup.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…o the community Follow-up to f9b1adb, addressing its review's doc nit. Docs only. channels.md and relay-queries.md said that after a lifecycle failure toast's Refresh channels, Channel settings reads its lifecycle actions from the writer for the rest of the session. The counter behind that, lifecycleRefreshes, lives in the channel navigation state. restore() rebuilds that state when the scope changes, and a ChannelNavigationState test pins the reset on a community switch. So after a refresh, switching to another community and back puts Settings on replica reads again. Behavior is fine, because the Archive/Unarchive/Delete/Leave/Hide preflight always reads the writer. Only the wording overstated it. - docs/channels.md: "for the rest of the session in that community (switching communities resets it)". - docs/relay-queries.md: "From the first such refresh in a community until the community changes". No comment in src/ repeats the claim. The lifecycleRefreshes and `refreshes` prop comments say only that each refresh rereads the actions and that later reads come from the writer, which still holds. Checked: git diff --check clean. The repo has no markdown formatter: Biome ignores .md, and prettier and markdownlint are not installed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: mtoohey <mtoohey@squareup.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…l switch Addresses kalvinnchau's review comment on PR 2778 (PRRT_kwDOUVULN860dV2P, against 24cb670; still present at 5529a67). When an owner or admin turned "Starter channel for new members" on or off and the HTTP publish came back 401 with `auth-required: authentication required`, the switch said "Only community owners and admins can change this." That prefix is kept for writers to match on, so relayRefusal returned undefined and the PublishRejected fell through to the permission copy. Before this branch the switch showed the raw `auth-required: authentication required`. - outbox: new authRefusal(error). For a sent PublishRejected whose `reason` starts with `auth-required:`, it returns the relay's words without the prefix and capitalized, clipped to the same 256 characters as relayRefusal. A 401 with NIP-FI's missing-evidence text now reads "Authentication required". That is the readable form transport's refusalMessage gives every non-kept prefix, and the same form this switch already shows for NIP-FI's 403 `restricted: authorization denied` ("Authorization denied"). The app has no shared copy for relay `auth-required:` refusals. The sign-in copy in CommunitySignIn maps native sign-in codes, and live-recovery and artifact-sync only classify the prefix. isRelayRefusal and relayRefusal are unchanged. - ChannelSettingsPanel AutoJoinSetting: tries authRefusal after relayRefusal. The permission copy now covers only rejections without relay words. The other relayRefusal callers don't have this problem. On an `auth-required:` refusal the emoji directory says "Failed to add emoji." and the workflow outbox keeps its fixed "Workflow command rejected…" copy. Neither claims a missing role, so both are unchanged. Tests: - ChannelSettingsPanel: the row that expected the permission copy for a kept prefix now expects "Authentication required" for the transport-shaped `auth-required: authentication required` refusal. With the authRefusal call removed from the panel, it fails with "Only community owners and admins can change this." - transport: a real 401 `auth-required: authentication required` through acceptPublish keeps its raw message and reason, is not a relayRefusal, and reads "Authentication required" from authRefusal. A 1000-character one is clipped to 256. - outbox: authRefusal returns nothing for an `auth-required:` refusal with no words, another relay refusal, or a write that was not sent. Checked: tsc --noEmit clean (exit 0). biome check clean on the 5 touched files. vitest for ChannelSettingsPanel, outbox and transport: 3 files, 155 tests passed. Not changed: a 409 conflict (client text, no reason) still shows the permission copy on this switch, as it did before this branch. `rate-limited:` and `conflict:` relay text don't reach this path with a reason: rate limits come back as 429, which isn't a kept refusal status, and 409 drops the relay text. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…he action Addresses kalvinnchau's review comment on PR 2778 (PRRT_kwDOUVULN860dV2L, against 24cb670; still present at de63146). An owner opened Channel settings, another owner demoted them, and they chose the Archive action Settings still offered. The "no longer permitted" toast then offered Refresh channels. Pressing Enter on it removed the focused button with no handoff, and the refresh then removed Archive and Delete. Focus ended on BODY, so the next Tab went to global chrome instead of the Settings pane. - ChannelNavigationState: the failure keeps the failed action's trigger and fallback. Refresh channels returns focus to the trigger, or to the fallback if the trigger is gone, the same way finalFocus does. It does this only when focus is still on the button or was lost, so it never pulls focus from somewhere else. The mute toast's buttons hand focus back to their row in the same way. - ChannelLifecycleActions: when a refresh or a live role change removes a focused Leave, Archive/Unarchive or Delete button, focus moves to the pane's fallback: the Settings-tab close control. A ref cleanup sees the focus before the button detaches. A microtask then moves it, but only if focus would otherwise sit on BODY. This is the pattern ActivityGroupActions uses for its retired Stop buttons. - ChannelLifecycleDialog: lifecycleFocusFallback holds the fallback lookup that openLifecycle used inline, so both owners share it. finalFocus uses the same focusOrigin helper as the toast. - docs/channels.md: one sentence on where focus goes after Refresh channels. Dismiss on this toast doesn't lose focus, so it is unchanged. Keyboard Dismiss returns focus to Archive both before and after this change. Sonner's fallback restores the element focused before the toast, and Dismiss doesn't refresh anything, so Archive stays. Tests: - ChannelsPage.tabs, real session: the demotion recovery test now focuses Refresh channels and presses Enter. A new `hold` option on the workspace fixture keeps the refresh read pending while the test checks that focus is back on Archive. After release, Leave replaces Archive and Delete, and focus settles on Close Channel settings tab. - ChannelLifecycleActions: a role change that removes a focused Archive moves focus to the pane's first button. If focus had moved to another control first, it stays there. Fail-before: - With all production files as at de63146, the ChannelsPage test fails on the toHaveFocus check right after Enter. - With only the Refresh handoff removed, it fails at the same check. - With only the retirement handoff removed, it fails at the final check. A throwaway probe in that state showed focus settled on BODY. - In the ChannelLifecycleActions test, removing the refs fails the first half, and removing both focus guards fails the second. Checked: tsc --noEmit exits 0. biome check is clean on the 5 touched source and test files. git diff --check is clean. vitest, 8 files, 278 tests passed: ChannelsPage.tabs, ChannelLifecycleActions, ChannelNavigationState, ChannelLifecycleMenu, ChannelSettingsPanel, ChannelsPage, ChannelsPage.solo, ChannelInventory. tests/browser/channel-lifecycle.spec.mjs in Chromium (--no-deps): 10 passed. That spec has no demotion recovery journey, so it is a regression check only. Not checked: the reviewer's flow in a real Chromium or WebKit build. jsdom covers the focus logic but not each engine's focus fixup when a node is removed. Not changed: the unused lifecycleRefreshes counter. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

Addresses kalvinnchau's review comment on PR 2778 (PRRT_kwDOUVULN860hDgx, against e425b65). Since e723bc0 the lifecycle permission preflight calls load() with strong reads before signing and again before publishing. Each preflight reads 39000, 39001 and 39002 by `#d`, so a Leave adds six strong filters. session-leave.test.ts counted every strong filter as a post-publish 39002 confirmation. It saw 7 or 8 where it expected 1 or 2, and all four cases failed. CI run 42221809235 failed JavaScript (6/6) and both Vitest flake checks on exactly these four. Leave itself still confirms. The confirmation is read([39002], id, signal, true, true): the only strong filter that carries `#p: [viewer]`. The test now keeps strong filters with `#p`, the same check membership-outbox.test.ts uses for its confirmations. The count (1 before ACK, 2 during readback) and the exact filter shape are unchanged. Production code is unchanged: the reviewer's diagnosis holds. Fail-before: at e425b65 all 4 cases fail ("got 7" and "got 8"). With the fix they pass. With the confirmation read made non-strong in channel-lifecycle.ts (temporary, reverted), all 4 fail again ("expected [] to have a length of 1"), so the narrower filter still checks the confirmation. Other tests that run lifecycle actions and look at strong reads: membership-outbox already narrows to `#d` plus `#p`. session-permissions, channel-lifecycle, ChannelsPage.tabs, ChannelsPage.solo and ChannelLifecycleActions passed in that CI run's other shards, so nothing else needed changing. Checked: tsc --noEmit exits 0. biome check is clean on the touched file. git diff --check is clean. vitest: session-leave 4, membership-outbox 21, session-permissions 18, 3 files, 43 passed. Not changed: Browser journeys (webkit, 9/14) in the same run failed notifications.spec.mjs:274 ("a fully visible incoming row stays quiet without publishing read intent"). This branch does not touch that spec or the notifications feature, and it was not investigated here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

…d option Addresses kalvinnchau's review comment on PR 2778 (PRRT_kwDOUVULN860hDg4, P3, against e425b65; still present at 39aa2a5). Since the rebase, Settings' ChannelLifecycleActions gets its actions from useLifecycleOffer. That derives them from the live channel summary (role, owners, archive state) and the shared owner-agent profile cache, and never calls channelLifecycle.load(). Two pieces added for the old Settings reread were left with no consumer: - ChannelNavigationState: `lifecycleRefreshes`. Refresh channels still incremented it and restore() still reset it, and its comment said Settings reread its actions on each one. Nothing reads it. Removed the field, comment, increment and reset. - channel-lifecycle: load()'s public `{ consistency }` option. Its only production caller, the /leave command in ChannelsPage.tsx, passes no option. Removed it from the interface and the capability. load() still uses ordinary routing. Kept, because they still have callers: - The internal strong load() that run()'s Archive/Unarchive/Delete/ Leave/Hide preflight uses before signing and again before publishing, including the strong owner-agent kind-0 reads. - refreshVisibility()'s `{ consistency }` option. The failure toast's Refresh channels uses it to reread DM visibility after a failed Hide. Docs: docs/channels.md and docs/relay-queries.md already describe the current behavior. channels.md says Settings' channel actions follow the refreshed channel state, and relay-queries.md lists the writer-backed discovery pass, the strong preflight and the Hide reread. Neither mentions a Settings reread any more, so neither changed. The focus comment in the toast handler still holds: ChannelLifecycleActions moves focus on when a refresh retires the focused action. Tests: - ChannelNavigationState: dropped the two counter assertions from the stale-failure test, which still checks the strong refreshList and that Archive's toast does not reread visibility. Dropped "resets lifecycle refreshes on session replacement and community switch", which only checked the counter, and the switchScope fixture helper only it used. - channel-lifecycle: dropped "a strong load reads channel state and owner profiles from the writer", which only checked the removed option. Strong preflight reads are still covered: "confirms %s while ordinary reads still see pre-write state" checks every preflight filter is strong, "authorizes from the writer when a replica predates %s" covers a direct role and owner-agent evidence, and the owner-agent Delete case checks both kind-0 reads are strong. Reworded one comment there that said Settings makes ordinary loads before a refresh. - The Hide reread is still covered in ChannelNavigationState ("also rereads DM visibility from the writer after an unconfirmed Hide") and ChannelsPage.tabs. Checked: tsc --noEmit exits 0. biome check is clean on the 4 touched files. git diff --check is clean. vitest, 7 files, 334 passed: channel-lifecycle 216, ChannelNavigationState 12, ChannelLifecycleActions 5, ChannelsPage.tabs 28, session-leave 4, revocation 51, session-permissions 18. The last two call load() with no option. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>

wesbillman

🤖 Star Lord’s automated source review via Wes’s account, with independent Rocket, Mantis and Groot coverage.

No new actionable integration findings at a947704e80666f989dc93d3c5e1f9c92538e2648 against c78fa990c2e8ee78aefb5620ca4ee5b9417f7e67. This follow-up retains the prior feature review and checks the rebase’s community-refusal observation, workflow-deletion delivery/echo handling, and reconnect/Refresh/focus integration.

The existing timeout-expiry readability finding remains unaddressed: the display helper still clips the relay’s Unix-seconds text without formatting it. This review does not supersede that feedback. The documented browser socket refusal-text limitation also remains.

Source-only: no tests, builds, CI verification or live workflows were run. The attached screenshot was inspected; the video was not played. The screenshot depicts an older branch revision and does not establish current-head behavior.

matt2e requested a review from a team as a code owner November 6, 2026 09:35

kalvinnchau reviewed Nov 6, 2026

View reviewed changes

Comment thread src/features/channel-navigation/ChannelNavigationState.tsx Resolved

Comment thread src/bundled/channels/ChannelSettingsPanel.tsx Resolved

matt2e force-pushed the no-reasons-provided-for-workflow-and-emoji-failures branch 2 times, most recently from a963b67 to 5529a67 Compare November 6, 2026 12:36

kalvinnchau reviewed Nov 6, 2026

View reviewed changes

Comment thread src/features/relay/channel-lifecycle.ts Resolved

Comment thread src/features/channel-navigation/ChannelNavigationState.tsx Resolved

wesbillman reviewed Nov 6, 2026

View reviewed changes

matt2e force-pushed the no-reasons-provided-for-workflow-and-emoji-failures branch from ace26fb to a12cb1a Compare November 7, 2026 00:30

wesbillman reviewed Nov 7, 2026

View reviewed changes

matt2e and others added 11 commits November 8, 2026 12:23

matt2e force-pushed the no-reasons-provided-for-workflow-and-emoji-failures branch from a12cb1a to a947704 Compare November 8, 2026 01:25

wesbillman reviewed Nov 8, 2026

View reviewed changes

Navigation Menu

Repository navigation

fix(relay, channels): show the relay's refusal reason and offer Refresh channels on stale lifecycle toasts - #2778

fix(relay, channels): show the relay's refusal reason and offer Refresh channels on stale lifecycle toasts#2778
matt2e wants to merge 11 commits into
mainfrom
no-reasons-provided-for-workflow-and-emoji-failures

matt2e commented Nov 6, 2026 •

edited

Loading

Uh oh!

kalvinnchau left a comment

Uh oh!

Uh oh!

Uh oh!

kalvinnchau left a comment

Uh oh!

Uh oh!

Uh oh!

wesbillman left a comment

Uh oh!

wesbillman left a comment

Uh oh!

tellaho commented Nov 7, 2026

Uh oh!

wesbillman left a comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

matt2e commented Nov 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Before and after

Notes for review

Testing

Uh oh!

kalvinnchau left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

kalvinnchau left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

tellaho commented Nov 7, 2026

Uh oh!

wesbillman left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

matt2e commented Nov 6, 2026 •

edited

Loading