[Bug]: Local message sends fail during history restore when an inactive SSH workspace shares the same path
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 62/100
Línea de trabajo
Start with coordinator.rs around lines 6415-6440, then trace session_store_port.rs and legacy_compat.rs to follow workspace identity and path-only resolution during history restore. Add regression coverage for new and restored local sessions alongside remote sessions and managed worktrees, preserving the diagnostic for ambiguous path-only resolution; done means a same-path inactive remote record no longer blocks the owning local session.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
A local session cannot send messages when an inactive SSH workspace record has the same absolute root path. Both an existing session and a newly created Standard session fail before a model request is made:
Session error: InvalidRequest: Session workspace_path does not resolve to a local workspace or a registered remote workspace: /Users/example/Project/home
The local directory exists and the session already has an explicit local workspace ID and execution target. Expected: history restoration should resolve the owning workspace by its ID, so a separately registered remote workspace with the same path does not prevent local conversations.
Area
Desktop app
Reproduction or evidence
- Register a local project such as
/Users/example/Project/home. - Register an SSH workspace whose root has the same path string.
- Leave the SSH workspace inactive. Its persisted record still exists even if it is absent from the open/recent lists.
- Select the local project and create a new Standard session.
- Send a short message, or retry a message in an existing session whose context must be restored.
- The send fails with the error above. Creating another session or switching models does not resolve it.
Observed workspace records, with identifying values replaced:
[
{
"id": "local_example",
"rootPath": "/Users/example/Project/home",
"workspaceKind": "normal",
"metadata": { "sshHost": "localhost" }
},
{
"id": "remote_example",
"rootPath": "/Users/example/Project/home",
"workspaceKind": "remote",
"status": "Inactive",
"metadata": {
"connectionId": "[email protected]",
"sshHost": "remote.example"
}
}
]
The newly created session carries the correct identity:
{
"workspaceId": "local_example",
"projectWorkspaceId": "local_example",
"workspacePath": "/Users/example/Project/home",
"projectWorkspacePath": "/Users/example/Project/home",
"workspaceHostname": "localhost",
"executionTarget": {
"kind": "local",
"rootPath": "/Users/example/Project/home"
}
}
Backend logs stop after context is empty, restoring from persistence and Starting session history restore. The Web UI then reports manage_dialog_queue failure with the error above. No model request is made for the failed send.
Recovery was verified on the affected install: after backing up the registry and removing only the inactive same-path SSH record while the app was stopped, the local record was the sole candidate after restart. The formerly failing new local session then accepted the greeting and completed a normal user/assistant turn in about 5.5 seconds. Existing local and remote session directories were retained. The restarted host also required clearing the stale local queue reminder and restoring the undelivered draft (queue_scope_expired) before a fresh submission could proceed.
Source-level cause
Inspected the source at the installed build commit, 39b27f5a8a65324c6cd9ca7dae614990f91791e5:
coordinator.rs, lines 6415-6440 callsresolve_session_restore_pathwith the path and optional SSH metadata, discarding the session'sworkspaceId/projectWorkspaceId.session_store_port.rs, lines 16-35 constructs a newSessionConfigwithout either workspace ID, then callsnormalize_session_workspace. Its.ok()?discards the underlying error.legacy_compat.rs, lines 52-73 finds both records for the path and returnsWorkspace path is ambiguous; select a workspace by its ID or saved SSH connection.
The resulting user-facing message incorrectly suggests that no workspace resolves, rather than reporting the discarded ambiguity.
Suggested fix: preserve the authoritative project/workspace ID through the history-restoration path and use resolve_workspace_storage when an ID is available. Keep path-only resolution at the legacy compatibility boundary and preserve its diagnostic error. Regression coverage should exercise a newly created local session and a restored local session with an inactive same-path remote registration, plus remote sessions and managed worktrees so history remains bound to the owning project.
Related but distinct: #2375 reported a same-path local/remote collision in rollback classification. This report concerns message submission and history restoration in 1.0.3.
Environment, if relevant
- OpenBitFun: stable desktop
1.0.3 - Installed build commit:
39b27f5a8a65324c6cd9ca7dae614990f91791e5 - OS: macOS
27.0.1(26A434) - Deployment: desktop on the local Mac, with a separately saved SSH workspace
- Agent: Standard
- Model/provider: failure occurs before model execution; reproduced with two model selections
- Workaround: back up the workspace registry, quit the app, remove only the unused same-path SSH workspace record, and restart. Closing the workspace or removing it from recent lists does not remove the conflicting record. Project files and session history are retained.
- Lenguaje dominante
- Rust
- Estrellas
- 2.3k
- Forks
- 236
- Merge medio
- 2 h 53 min
- PR fusionados (30 d)
- 404
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de GCWing/OpenBitFun
-
Dificultad 2/5 Medio día Aptitud para principiantes 74/100
GCWing/OpenBitFun#3279 ·
Los mantenedores suelen responder en 1 día
-
[Bug]: 界面写“敏感诊断信息默认关闭”,但后端配置当前实际默认是 truePosiblemente ocupada @xiechimon la tomó hace 13 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
GCWing/OpenBitFun#3213 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
GCWing/OpenBitFun#2363 ·
Los mantenedores suelen responder en 1 día
-
question
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
GCWing/OpenBitFun#2340 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
GCWing/OpenBitFun#3278 ·
Los mantenedores suelen responder en 1 día
Todos los issues de GCWing/OpenBitFun
Issues similares
-
feature request good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
TabularisDB/tabularis#853 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
andrewdavidmackenzie/jonesy#267 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 4 días
-
`future_into_py` loses the original panic messagePosiblemente ocupada @Danipulok la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
PyO3/pyo3-async-runtimes#91 ·
-
Signals (Failure Detector): a tool call and its own execution are reported as a repeated callAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día