WebShell无法使用

[yjps]

Ready
Connecting to server...
WebShell task created successfully

Connection dropped, retrying in 1s...

Connection dropped, retrying in 1s...

Connection dropped, retrying in 1s...

Connection dropped, retrying in 1s...

WebSocket error occurred

Disconnected [code: 1006]

该怎么办啊？和ssh端口有关系吗？我没有用22端口。

[GenshinMinecraft]

webshell 和 ssh 无关，ssh 无法连接的问题近期有人反馈，没有找到问题

可能是迁移途中有代码改了，等会解决

[York618]

个人推测是因为Tokio 任务未中止和 Channel 引用计数未归零导致的经典死锁/挂起 Bug，具体分析如下

1. 所有权被夺走后无法归还：
   当用户通过浏览器连接时，handle_user 执行 rx_from_agent.take() 拿走了 SessionSlots 中的 Receiver。此时 Slot 中的 rx_from_agent 变成了 None。
2. tokio::select! 丢弃 JoinHandle，但不中止 Task：
   在 terminal.rs (line 438)中：

   tokio::select! {
       biased;
       _ = recv_task => {},
       _ = send_task => {},
   }

   当用户主动断网/刷新浏览器时，浏览器的 WebSocket 连接断开，导致 send_task（用户 WS -> Agent Channel）退出。此时 select! 唤醒并执行完毕，handle_user 函数直接返回。
   关键在于：在 Tokio 中，直接丢弃（drop）recv_task 的 JoinHandle 并不会中止正在运行的异步 Task。
3. 悬挂任务（Leaked Task）阻塞 Channel 释放：
   未被 abort 的 recv_task 依然在后台运行，并被卡在 rx_from_agent.recv().await 上。
   因为 recv_task 还活着，它持有的 rx_from_agent 就不会被 Drop。
4. Agent 侧无法感知断开：
   在 handle_agent 中，如果 Shell 当前是闲置的（没有输出），Agent 侧的 send_task 会一直 block 在读取 Agent 自身的 WebSocket 上 (ws_receiver.next())，根本不会向 tx_to_user 发送数据，因此无法感知 tx_to_user 是否被关闭。
   同时，state.sessions 里的 SessionSlots 从未被移除，因此它持有的 tx_to_agent 仍然存活。这导致 handle_agent 的 recv_task 卡在 rx_from_user.recv() 上永不返回（因为 Sender 计数不为零，通道不关闭）。
5. 重连灾难：
   此时，Agent 侧的 PTY 进程、WebSocket 以及 Server 侧的槽位依然被占满。当用户刷新页面，用同一个 terminal_id 尝试重新连接时，Server 会在 map 中找到该 Slot，但由于 rx_from_agent 已经是 None，因此会直接报 Terminal session already has an attached user 错误，导致用户永远无法重新连入该会话。

[York618]

个人推测是因为Tokio 任务未中止和 Channel 引用计数未归零导致的经典死锁/挂起 Bug，具体分析如下

1. 所有权被夺走后无法归还：
   当用户通过浏览器连接时，handle_user 执行 rx_from_agent.take() 拿走了 SessionSlots 中的 Receiver。此时 Slot 中的 rx_from_agent 变成了 None。

2. tokio::select! 丢弃 JoinHandle，但不中止 Task：
   在 terminal.rs (line 438)中：
   tokio::select! {
   biased;
   _ = recv_task => {},
   _ = send_task => {},
   }

   当用户主动断网/刷新浏览器时，浏览器的 WebSocket 连接断开，导致 send_task（用户 WS -> Agent Channel）退出。此时 select! 唤醒并执行完毕，handle_user 函数直接返回。
   关键在于：在 Tokio 中，直接丢弃（drop）recv_task 的 JoinHandle 并不会中止正在运行的异步 Task。

3. 悬挂任务（Leaked Task）阻塞 Channel 释放：
   未被 abort 的 recv_task 依然在后台运行，并被卡在 rx_from_agent.recv().await 上。
   因为 recv_task 还活着，它持有的 rx_from_agent 就不会被 Drop。

4. Agent 侧无法感知断开：
   在 handle_agent 中，如果 Shell 当前是闲置的（没有输出），Agent 侧的 send_task 会一直 block 在读取 Agent 自身的 WebSocket 上 (ws_receiver.next())，根本不会向 tx_to_user 发送数据，因此无法感知 tx_to_user 是否被关闭。
   同时，state.sessions 里的 SessionSlots 从未被移除，因此它持有的 tx_to_agent 仍然存活。这导致 handle_agent 的 recv_task 卡在 rx_from_user.recv() 上永不返回（因为 Sender 计数不为零，通道不关闭）。

5. 重连灾难：
   此时，Agent 侧的 PTY 进程、WebSocket 以及 Server 侧的槽位依然被占满。当用户刷新页面，用同一个 terminal_id 尝试重新连接时，Server 会在 map 中找到该 Slot，但由于 rx_from_agent 已经是 None，因此会直接报 Terminal session already has an attached user 错误，导致用户永远无法重新连入该会话。

解决起来也很简单，做一个检测和超时未交互自动结束就行了
奉上我的commit