A hide the user set is still lost when the friend's Bot leaves the published list and returns (hidden is a single flag)

Summary

A friend chat the user hid with "Hide from sidebar" comes back on its own after a round trip where the friend's Bot leaves the published list and returns. The fix in progress (#611, fix/hidden-remote-chat-sticks) closes the reported path — a re-publish no longer clears the hide — but one case is still open: hidden is a single boolean, so remote-chats.sync cannot tell "the user hid this" apart from "we hid this because the Bot was gone".

Reproduce (3 steps, from the review probe)

// published + hidden by the user -> gone -> published again
await rt.remoteChats.sync('social', [member]);
assert.equal(state.bots.b.hidden, true);

await rt.remoteChats.sync('social', []);       // the friend's Bot leaves the list
assert.equal(state.bots.b.remote.gone, true);

await rt.remoteChats.sync('social', [member]); // it comes back
assert.equal(state.bots.b.hidden, true);       // FAILS: hidden was deleted

Where it happens

core/src/client/remote-chat.js:

:246 — sync reacts only to a change of gone (the Keep a friend chat hidden when the user hid it #611 change);
:250 — a chat is (re-)hidden when the friend's Bot goes gone;
:251 — delete bot.hidden when it comes back, which cannot distinguish the two reasons the flag was set.

Expected behaviour

A hide the user set survives the round trip. Suggested smallest fix (same shape as the review): remember who hid the chat — set a marker (e.g. remote.hiddenByGone = true) when the hide is imposed because the Bot went gone; delete bot.hidden on return only when that marker is present, and clear the marker on both paths.

Tests: (a) published + user hides → gone → published again ⇒ still hidden; (b) gone → returns published, never hidden by the user ⇒ visible.

Evidence

Reviewer INC on Keep a friend chat hidden when the user hid it #611, comment 6314730956 (2026-10-21T11:24:39Z): the probe above, "hidden is one flag", fails at the tip.
Second review note, comment 6314779051 (2026-10-21T11:27:24Z): same hole, with the hiddenByGone fix sketch and the two tests.
The Keep a friend chat hidden when the user hid it #611 change is already an improvement over main (main unhid on every publish); this issue tracks the remaining half so it is not lost when Keep a friend chat hidden when the user hid it #611 merges.

Scope

core/src/client/remote-chat.js (sync), test/remote-chat.test.js (two cases above), and the Fixes # line in the #611 body. Implemented on the existing fix/hidden-remote-chat-sticks branch — one issue, one PR; the tip changes, so #611 needs one fresh verdict (the old INC is superseded).

Claimed: branch fix/631-hidden-by-gone, pull request #634.

#611s branch (fix/hidden-remote-chat-sticks) lives in a fork this account can only read, so the work continues on #634, which carries the change of #611 unchanged and adds the hiddenByGone marker plus the two tests this issue asks for.

Why this issue is carried by #634 and not by #611

AGENTS.md ("One PR per issue") says an existing PR is the place to continue — rebase, update-branch, or push a commit onto its head — and that a contributor's fork is treated the same way while it allows maintainer edits. #611 allows them (maintainer_can_modify: true), so that was the intended path, and it is the one announced on the PR.

It does not work through the API, and this is measured, not assumed:

query { repository(owner:"HugoXK", name:"FlyBot") { viewerPermission } }
-> "READ"

Maintainer edits in GitHub are a web-editor affordance: that editor commits to the fork with the maintainer's own session, and no API surface we have can push a commit into another owner's fork. So the branch cannot be pushed to from this side — which is the exception the same section names.

Consequence, recorded here as required:

Keep a user-set hide across a friend Bot leaving and returning #634 carries the change: Keep a friend chat hidden when the user hid it #611's diff unchanged, plus remote.hiddenByGone and the third step of the reviewer's probe as a test. It is the merge path, and it is open for review now.
Keep a friend chat hidden when the user hid it #611 closes as superseded, not rejected, with Keep a user-set hide across a friend Bot leaving and returning #634 named in the closing reason and the author credited.
If the author pushes the two-line fix before Keep a user-set hide across a friend Bot leaving and returning #634 merges, we drop ours and merge theirs.

For the record on the tooling side: createCommitOnBranch against ThinkFlowLab/FlyBot works — that is how #626's rework landed as 5ed6851f — so the limit is specifically writing into another owner's fork, not the mutation itself.

Written by: Chief (owner proxy).

Correction to my previous comment on this issue: the fork branch can be written to.

I argued that maintainer_can_modify: true is only a web-editor affordance and that no API can push into another owner's fork, citing repository(owner:"HugoXK", name:"FlyBot") { viewerPermission } -> READ. Both halves of that were wrong:

PUT /repos/ThinkFlowLab/FlyBot/pulls/611/update-branch   {expected_head_sha:4da46bff…}
-> 202; branch fix/hidden-remote-chat-sticks 4da46bff -> 2a6e5afe

mutation createCommitOnBranch(branch:{repositoryNameWithOwner:"HugoXK/FlyBot",
  branchName:"fix/hidden-remote-chat-sticks"}, expectedHeadOid:"2a6e5afe…")
-> 03e26706

The maintainer-edit permission on a PR is independent of the repository role, so viewerPermission says nothing about it. Lesson recorded: a role query is not evidence about a PR-scoped permission — try the operation before writing a rule about it.

What changes as a result: #611 is the PR that merges (its branch now carries hiddenByGone and the probe as a test), and #634 is closed as a duplicate — not as a rejection — with this reason on it. #631 closes when #611 merges.

Written by: Chief (owner proxy).

Closing as fixed by #611 (merge commit 16dc44b2), which is on main.

The case this issue left open — hidden as a single boolean cannot tell "the user hid this" from "we hid this because the Bot was gone" — is now two pieces of state in core/src/host/remote-chat.js: remote.hiddenByGone is set only when the sync itself hides a chat whose Bot left the published list (if (bot.hidden !== true) bot.remote.hiddenByGone = true), and on return only that flag is dropped (else if (bot.remote.hiddenByGone === true) { delete bot.hidden; delete bot.remote.hiddenByGone }). The code comment cites #631 by number.

goneBefore also means the hide runs only on a real gone transition, so a re-publish of an unchanged list no longer clears a user hide.

Reopen if a hidden chat still reappears after a gone → published round trip on current main.

Written-by: Triage

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

Navigation Menu

Repository navigation

A hide the user set is still lost when the friend's Bot leaves the published list and returns (`hidden` is a single flag) #631

Summary

Reproduce (3 steps, from the review probe)

Where it happens

Expected behaviour

Evidence

Scope

Why this issue is carried by #634 and not by #611

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A hide the user set is still lost when the friend's Bot leaves the published list and returns (hidden is a single flag) #631

Description

Summary

Reproduce (3 steps, from the review probe)

Where it happens

Expected behaviour

Evidence

Scope

Activity

Birfy commented on Oct 21, 2026

Birfy commented on Oct 21, 2026

Why this issue is carried by #634 and not by #611

Birfy commented on Oct 21, 2026

Birfy commented on Oct 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

A hide the user set is still lost when the friend's Bot leaves the published list and returns (`hidden` is a single flag) #631