github / github/copilot-cli

General Chat is silently archived after session resume timeout, with no restore UI

未关闭
#4,474 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

area:platform-windows area:sessions
主要语言
Shell
星标
11.2k
派生
1.9k
平均合并
14 小时 16 分钟
30 天内合并 PR
6

描述

Summary

A long-running General Chat was silently archived when the app failed to resume it within 60 seconds. I did not archive or delete the chat. The app automatically created a replacement chat, while the original disappeared from the sidebar with no UI to view or restore archived chats.

Environment

  • GitHub Copilot app: 1.1.8 (0945da4)
  • Bundled Copilot CLI: 1.0.79-9
  • OS: Windows x86_64

Observed behavior

  1. Opened an existing General Chat with substantial history.
  2. The UI appeared unresponsive for about a minute.
  3. The original chat disappeared and a newly created chat became active.
  4. The original chat was absent from the session list.
  5. Attempting to navigate to its ID returned: This chat is archived. Restore it before continuing.
  6. There is no archived-chat list or Restore action in the app UI.

The local database showed that the original general_chat row received an archived_at value at exactly the same time the replacement session was created. Clearing only that archived_at value restored the original chat and its full history, confirming the data had not been deleted.

Relevant sanitized log timeline

09:36:25 resuming session ... session_type=GeneralChat
09:37:25 session resume timed out; releasing CLI and surfacing error ... timeout_secs=60
09:37:26 Failed to resume session ... the CLI process may be unresponsive, attempting to recreate
09:37:26 Recreating session old_session_id=<original>
09:37:33 CLI session created cli_session_id=<replacement>
09:37:33 SessionManager create_session flow completed session_id=<replacement>

The original row's archived_at timestamp was 09:37:33.779, immediately after the replacement session was created.

Expected behavior

  • A resume timeout must not silently archive an existing chat.
  • If a replacement process/session is needed, the existing chat identity and history should remain visible and recoverable.
  • The app should surface the timeout and offer Retry rather than replacing the chat without consent.
  • If chats can be archived, the UI must provide an Archived view and Restore action.

Impact

This looks like data loss to the user and strands important long-running chat history. Recovery currently requires manually editing the app's SQLite database, which is not a safe or reasonable user workflow.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

首先重现 60 秒的 resume 超时,并结合本地 SQLite 行中 archived_at 的变化检查 SessionManager create_session 流程。确认原始聊天仍然可见且可恢复,超时反馈提供 Retry,并且已归档的聊天具有查看视图和 Restore 操作。

由索引模型根据 Issue 内容生成。

评估

技术栈
sqlite
领域
cli, database
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
冷清
描述清晰度
基本清楚
新手友好度
48/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。