🤖 fix: the Daytona status badge stays stopped after an editor open starts the sandbox
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 76/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- react, typescript
Línea de trabajo
Empieza por src/browser/utils/openInEditor.ts:450 y sigue el flujo de admisión del editor junto con useOpenTerminal y utils/terminal.ts, que ya actualizan el estado de ejecución después de abrir un terminal. Añade la actualización después de que la admisión del editor de Daytona se realice correctamente y, después, añade la prueba descrita con el estado stopped en caché y verifica que espera una actualización.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Follow-up from the Codex review of #7100 (thread: https://github.com/coder/xum/pull/7100#discussion_r4354242893, src/browser/utils/openInEditor.ts:450).
Problem
Opening a Daytona workspace in an editor (VS Code, Cursor, Zed) while its sandbox is stopped goes through recordEditorOpen, whose backend readiness starts the sandbox. The editor path then returns without refreshing RuntimeStatusStore. An editor open happens outside a turn, so no runtime-status event corrects the cache: the runtime badge keeps showing "Sandbox Stopped", and the Git and PR stores stay blocked by canRunPassiveRuntimeCommand until the window regains focus or metadata refreshes.
The terminal path already handles this: useOpenTerminal and utils/terminal.ts call getRuntimeStatusStoreInstance().refreshAfterTerminalOpen(workspaceId) after the terminal opens.
Proposed fix
After the editor admission succeeds for a Daytona workspace, call the same immediate status refresh the terminal path uses (rename it to fit both callers if needed). Add a test that opens an editor with a cached stopped status and expects one status refresh.
Why it is deferred
#7100 runs its review loop under a P0/P1-only rule; P2 findings get a tracked follow-up.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.1k
- Forks
- 140
- Merge medio
- 4 h 57 min
- PR fusionados (30 d)
- 946
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
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 coder/xum
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
coder/xum#7358 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
coder/xum#7302 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
coder/xum#7283 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
🤖 fix: a Daytona connection test started before a settings save can show the old key as connectedAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
awesome-dsh-plugin/awesome-dsh-plugin#9184 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
farion1231/cc-switch#8829 ·
Los mantenedores suelen responder en 1 día
-
[core-client] Remove unused hand-maintained transport helpers after the definition-table cutoverAbiertodoc-audit enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100