From 82f1bb817ef48d4693f271e1ab0672d2c74bbdf6 Mon Sep 17 00:00:00 2001 From: Narasimha-sc <166327228+Narasimha-sc@users.noreply.github.com> Date: Sat, 17 Oct 2026 20:41:50 +0000 Subject: [PATCH] plans: channel creation stops updating when owned channel relays open --- ...26-10-17-channel-creation-group-members.md | 2 +- plans/2026-10-17-channel-creation-relays.md | 50 +++++++++++++++++++ 2 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 plans/2026-10-17-channel-creation-relays.md diff --git a/plans/2026-10-17-channel-creation-group-members.md b/plans/2026-10-17-channel-creation-group-members.md index f83d813fed..2f75cec7ce 100644 --- a/plans/2026-10-17-channel-creation-group-members.md +++ b/plans/2026-10-17-channel-creation-group-members.md @@ -28,7 +28,7 @@ Alternatives considered: - Reload the open group's members after the creation ends. Rejected: the wrong list still shows during the creation. Not changed here: -- `ChannelRelaysModel` is also shared between the channel being created and an open channel you own (its relay bar disappears during creation); a separate fix. +- `ChannelRelaysModel` is also shared between the channel being created and an open channel you own (its relay bar disappears during creation); fixed separately, see `2026-10-17-channel-creation-relays.md`. - When the creation screen is closed from outside (e.g. a notification on Android), the channel stays marked as being created; its member updates now go only to the separate list. ## Verification diff --git a/plans/2026-10-17-channel-creation-relays.md b/plans/2026-10-17-channel-creation-relays.md new file mode 100644 index 0000000000..c460b596b3 --- /dev/null +++ b/plans/2026-10-17-channel-creation-relays.md @@ -0,0 +1,50 @@ +# Channel creation stops updating when an owned channel's relays are opened + +Follow-up of #7746 (builds on its branch). + +## Problem + +On desktop the channel creation flow runs in the left pane while a chat stays open next to it. With a channel you own open, opening its "Chat relays" while another channel was being created left the creation at "0/3 relays active": it never updated again, also after the relays view was closed, although the channel was ready (after a restart it was a normal channel with its relays). A user would likely cancel it, which deletes the channel. + +In the other direction, a creation hid the open channel's relay bar (shown while some of its relays are not active) during the creation and, after a cancel, until the channel was opened again. + +Reproduced on master with the GUI (desktop). + +## Cause + +`ChannelRelaysModel` holds the relays of one channel (`groupId` + `groupRelays`). It was used both by the channel being created (`AddChannelView`: `set` when it is created, read by the progress step, `reset` on cancel and when ready) and by an open channel you own (`ChatView` when it opens, `ChannelRelaysView`, `AddGroupRelayView`; read by the relay bar in `ComposeView`). `GroupRelayUpdated` and `GroupLinkDataUpdated` update it only for its current `groupId`. + +When the open channel's relays view loaded its relays, the model switched to that channel; the progress step ignores values of another channel and the events for the channel being created were dropped, so its progress stopped. The creation's `set` and `reset` in turn replaced or cleared the open channel's relays. + +## Fix + +Keep the relays of the channel being created in their own list, `ChatModel.creatingChannelRelays` (like `creatingChannelMembers` in #7746): +- set from the creation result, before the channel is marked as being created; +- `GroupLinkDataUpdated` replaces it and `GroupRelayUpdated` adds or replaces a relay when the event is for the channel being created; +- the progress step reads it; `AddChannelView` no longer writes `ChannelRelaysModel`. + +Alternatives considered: +- Only drop the progress step's `groupId` check: it would show, and could complete on, the open channel's relays. +- A per-channel map in `ChannelRelaysModel`: changes every reader. +- Updating the new list inside `ChannelRelaysModel.updateRelay`: ties it to `ChatModel`; the `GroupLinkDataUpdated` update stays in `SimpleXAPI.kt` anyway. + +Behavior change: after "Continue" with relays still pending, the new channel's relay bar shows once its chat has loaded its relays (as after an automatic completion), not at once. + +Not changed here: +- iOS likely has the same bug: it shares its `ChannelRelaysModel` between the channel being created and an open channel the same way (`AddChannelView.swift`, `ChannelRelaysView.swift`, `ChatView.swift`). +- `ChatView`'s cleanup on close still skips while a channel is being created; with this change and #7746 the channel being created no longer uses that state. + +## Verification + +Desktop Linux AppImage, #7746's head (before) vs this branch (after). + +The bug needs the relays view to load while the creation is in progress; relays usually connect in ~10 s, so on plain builds it was hit once in 5 attempts on master and not at all in 2 counted attempts on #7746's head. The bug check therefore ran on test builds of both that hold back each relay update of the channel being created by 5 s (not part of this change): + +| # | Check | before | after | +|---|---|---|---| +| D0 | Creation with no other action | completes (~40 s) | completes (~40 s) | +| D1 | Channel chX open, create chY, open chX's "Chat relays" at 0/3 | chY stays at "0/3 relays active", all relays "invited", for 150 s, and 30 s more after the view is closed; after a restart chY is a normal channel with 3 active relays | 1/3, then chY opens ~17 s later | + +Plain builds, identical on both: chX's "Chat relays" lists its 3 active relays; a creation completes, opens the channel with its link page, its info lists 3 relays and messages send; cancel removes the channel and chX's messages send; no relay bar above chX's composer (all relays active) before and after a creation and a cancel. No crashes or `E:` log lines. + +Android (Waydroid debug APKs, #7746's head vs this branch, same snapshot), identical: creation, "Continue" to the channel and sending, cancel, an owned channel's "Chat relays" and sending. No crashes.