fix: remote session discovery gating and empty replay on remote open (0.3.1) - #51
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two remote-access fixes found while debugging live hub state, plus the 0.3.1 release bump.
Fix 1 — discovery no longer lists never-used sessions (
cd1b58c)Root cause: an editor restart auto-resumes its stored
session/newplaceholder, which materializes an empty backend session. The bridge pushed every registered session to the hub, so remote clients listed (and opened) conversations that never happened.Fix: session summaries carry a
hasActivityflag, set only by real interaction — a completed prompt turn (any outcome), asession/loadwith replayable history, or an adopted stored title.sessionsPayloadfilters on it. The hub replaces the session list on every register, so entries appear/disappear within one heartbeat (~10s).Fix 2 — old conversations opened empty on remote clients (
40b7209)Root cause: the backend subprocess only answers
session/messagesfor sessions it has loaded viasession/create/session/resume. The bridge'salreadyLivecheck trusted the in-memory id mapping, which can exist without the session ever being loaded into the current backend (re-registered from the durable store, or left behind by a failed resume) — sosession/loadskipped the resume RPC and replayed nothing.fetchMessagesalso swallowedsession/messageserrors as empty, masking it. Verified live: the affected session returnedtotalMessages: 0by ACP id but 352 messages / 52 turns after a forced resume — data intact, purely a bridge-side skip.Fix: explicit
backendLoadedSessionstracking — stamped only after a successful create/resume RPC;resolveResumeTargetskips the resume RPC only for verified sessions, otherwise re-issues it.fetchMessagesnow warns on errors instead of silently replaying empty.Testing
Docs
REMOTE-CLIENTS (sessions list semantics), TROUBLESHOOTING (empty-conversation-on-remote section), CHANGELOG 0.3.1.