[itz4blitz]

Cause

#51 makes a Watch sent before READY take effect once READY arrives. A Members request sent in that same window still failed. members.rs::members looks the conversation's server up in state.guilds, which READY fills, and answered Error { Unsupported, "Discord cannot do this yet" } when the server was missing. On a restart the stored tree is on screen before READY, so this happens as the app opens.

The GUI treats that answer as a final failure, not as data still to come:

• The member pane (gui/people/members.rs::landed) records the page as failed, shows "Couldn't load members" and does not retry. Only Offline, slow or gone sockets, and "Discord did not send the member list." are retried.
• The details pane (gui/people/info.rs::ask_members) ignores any answer that is not Members, so its inline members never come.

So a list opened while connecting stayed empty after the account connected. Issue #43 asks that "a member-cache miss should not be mistaken for an empty roster", and this was one.

Fix

In members.rs::members: if the server is unknown and no server is known at all (state.guilds is empty, i.e. READY has not said what they are), answer Members { pending: true } with no sections or members. That is the answer a cache miss after connect already gets. Watched is left alone, so nothing is placed or subscribed from the early request. READY's rewatch (#51) places the Watch.

Both GUI callers already handle pending: they re-ask every 250 ms while the page is wanted. After READY the next ask opens the list, the window is subscribed, and the members fill when Discord's SYNC arrives. Once any server is known, a request for one that is not is still refused as before. That case covers a server the user has left whose conversations are still stored.

Known edge: an account in no servers at all, asking for a stored conversation of a server it has left, now gets pending (the pane keeps polling locally) and not the refusal. That needs an account with zero servers, and the polls are local cache reads.

Validation

• New integration test members_asked_before_ready_are_pending_and_fill_after_connect in crates/chatd/tests/discord.rs. It connects once so the server is stored, then delays READY 1.5 s with fix: subscribe the Discord member viewport a Watch chose before READY #51's ready_after and restarts chatd. It asks for 4105's members before READY and asserts they are pending and empty. It waits for Connected, asks again until the op 37 for 4105 goes out, pushes a SYNC, and asserts the members fill. On main it fails with Error { code: Unsupported, detail: "Discord cannot do this yet" }. It passes with this change.
• The new test and fix: subscribe the Discord member viewport a Watch chose before READY #51's member_viewport_selected_before_ready_is_subscribed_after_connect, run together 5 times: 5/5 passed.
• cargo test -p chatd --test discord: 32 passed.
• cargo test -p chatd: 292 passed, 0 failed, 0 ignored (136 lib unit tests, plus blobs 14, calls 10, discord 32, e2e 25, messages 5, playback 4, polish 12, signal 10, slack 15, teams 7, telegram 17, upload 5).
• cargo clippy -p chatd --all-targets: nothing in the touched files. On main clippy already stops at gateway.rs's while beat.ready (clippy::while_immutable_condition, from fix: pace Discord member subscriptions so a scroll cannot spend the Gateway budget #52), which this PR does not touch. With that lint allowed, it is clean here.

Refs #43

🤖 Generated with Claude Code