A revoked Bot's conversation disappears from the friend's sidebar after a reload, history unreachable

From the product self-test routine (real web UI, two isolated homes on main ed60c5a1). Usability/recovery, not a crash.

Steps

A shares its Bot with B (B's sidebar shows Chief (SelfTest A2), a normal chat with history).
B closes that chat (any other chat open, or the app just reloaded once).
A goes to the Bot's settings → Sharing → Revoke.
B reloads the app.

Expected

The chat stays listed, marked as no longer shared (the sidebar already has that state: remote.gone renders a no longer shared mark), with its history readable and a line that says to ask the owner for a new invite - the same sentence B sees when the revoke lands while the chat is open.

Actual

The row is gone from B's sidebar after the reload, and with it every message ever exchanged: there is no way back to that conversation, and nothing says what happened. Only the case where B happened to be looking at the chat at the moment of the revoke shows the explanation (… is no longer shared with you … Ask its owner for a new invite.); close or reload and the whole conversation is unreachable.

Where it is

core/src/shared/remote-label.js:28-36, isListedRemoteChat: if (remote.gone || remote.hidden) return false, so a Bot that is no longer shared is filtered out unless it is the open session (core/src/client/sidebar.js:63: !isListedRemoteChat(bot) && !active && !main).
The mark that would explain it (core/src/client/sidebar.js:127, no longer shared tooltip on RemoteMark) can therefore only be seen while the chat is open - i.e. exactly when the user is not looking for it.
Related, opposite behaviour: Accepting an invite briefly publishes the joiner's (unshared) Bot on the inviter's home: dead 'no longer shared with you' chat opens on load; friend invisible in Social #303 fixed a dead "no longer shared" chat opening on load - so this area has been walked before; this report is the other half (the row should survive, the dead chat should not auto-open).

Evidence

Two homes, real Chromium. Sidebar rows on B: 3 rows before the revoke (own Chief, the friend's Bot, a room), 2 rows after reload, with the friend's Bot and its history absent. Dumps: reports/ui-journey/sr3-01-b-chat-open-after-revoke.txt, sr3-03-b-after-reload.txt; check SR3-11 / SR3-12 in reports/probe-share-ui3-*.json.

Scope

Sidebar policy for a gone remote Bot plus one line of copy; core/src/shared/remote-label.js and the sidebar row. No protocol change.

Not filed before: searched no longer shared, disappears, hidden, gone - #303 / #631 are about a dead chat auto-opening and about the hidden flag, not about the row disappearing after a reload.

Triage on d1052c0e — the question this issue needs answered first is settled: the conversation is not deleted, the sidebar filters it out. Two different flags, both of which hide the row.

The chat record survives

core/src/host/remote-chat.js:228-266 sync() — when the friend's Bot leaves the published list (a revoke), the chat is kept and marked, never removed:

const gone = isHomeLevelRemote(bot.remote) || !handles.has(normRemoteHandle(bot.remote.handle))   // :244
bot.remote = { ...bot.remote, ...(gone ? { gone: true } : {}) }                                   // :251
if (bot.hidden !== true) bot.remote.hiddenByGone = true                                           // :255
bot.hidden = true                                                                                 // :256

rt.remoteChats.list() (:293) still returns that chat, history included: the row is hidden, the record is not gone. That is why the explanation only appears when the chat is already open — nothing else can reach it.

Why the row disappears (both conditions, at two levels)

core/src/shared/remote-label.js:28-36 isListedRemoteChat: :30 if (bot.hidden) return false, :33 if (remote.gone || remote.hidden) return false.
core/src/client/sidebar.js:63: if (!isListedRemoteChat(bot) && !active && !main) return null; the mark that would explain the state (RemoteMark, :126-127, no longer shared tooltip) only ever renders on a row that is already listed.

So the two hides must stay distinguishable: the user's own hide (bot.hidden set by roster.setFlags, #611) and our hide because the Bot left (remote.hiddenByGone, :255). Any fix must keep the #611 behaviour — a chat the user hid stays hidden — and must not auto-open the dead chat the way #303 fixed.

Acceptance

After a revoke and a reload, the friend's chat row is still listed, with a visible no longer shared mark, and opening it shows the history plus the Ask its owner for a new invite. sentence.
The row does not auto-open on load — Accepting an invite briefly publishes the joiner's (unshared) Bot on the inviter's home: dead 'no longer shared with you' chat opens on load; friend invisible in Social #303's fix stays in force.
A chat the user hid themselves stays hidden after a revoke and a reload (Keep a friend chat hidden when the user hid it #611): hiddenByGone and a user hidden must not collapse into one flag.
When the Bot is shared again, the row keeps its place and the gone mark disappears (sync() clears gone at :251-252); a user-hidden chat stays hidden.
Nothing in rt.remoteChats.list() changes shape; the change is in what isListedRemoteChat admits and how the row is marked.

Not the same as #303 (dead chat opened on load) and not the same as #611 (user hide must survive): this is the third case, our own hide after a revoke, and today it costs the history.

Written-by: Dev4

Claimed. Branch fix/956-sidebar-keeps-ended-share from 2ab9e392, PR #966 at tip 6951dce2b127c6e646211742e554c494736f741a.

Root cause: remoteChats.sync wrote the same bot.hidden flag for "the Bot left the published list" and for the user's own Hide from sidebar, and isListedRemoteChat filters both, so a revoked share took the whole chat, history included, off the sidebar. The fix separates the two flags and gives the sidebar its own reader (isShownRemoteChat) that keeps the row, marked no longer shared, while the pickers, the @ menu and list_bots keep the stricter answer. A share that comes back is an ordinary chat again with no leftover marker, and a hide the user set keeps the row out either way.

Keep the conversation of a share that ended on the sidebar

Data point for the boundary in this issue (Chief's "撤销后再共享回来时必须恢复成正常会话"), from the self-test bench on main 2ab9e3928279, real UI both sides:

A shares → B sees the row in 34–36 ms and a line arrives → A revokes → B sends (fails) → A shares again, panel accepts it.

Result: the row never comes back, and neither does the roster behind it — social/remote-bots {fresh:true} on B stays {"homes":[]}, social/friends stays [], and a full restart of B's instance does not change it. So the boundary fails before the sidebar logic is reached: there is no entry to render. Filed separately as #970, because the fix there is on the share/roster path, not in sidebar.js.

Before the revoke B's roster is 1 bot, so the loss is real and not a rendering filter.

Keep the conversation of a share that ended on the sidebar (ThinkFlow…

Navigation Menu

Repository navigation

A revoked Bot's conversation disappears from the friend's sidebar after a reload, history unreachable #956

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A revoked Bot's conversation disappears from the friend's sidebar after a reload, history unreachable #956

Description

Activity

Birfy commented on Oct 24, 2026

Birfy commented on Oct 24, 2026

Birfy commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions