🤖 fix: keep SSH access to a Daytona sandbox when its delete fails
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
- 78/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
Línea de trabajo
Empieza cerca de la línea 258 de src/node/services/daytona/daytonaSandboxes.ts y sigue deleteSandbox, ensureSshAccess y las comprobaciones SSH de la ruta de eliminación. Añade la prueba descrita: el primer intento de eliminación falla con un 5xx y luego un reintento tiene éxito. Se considera terminado cuando las comprobaciones SSH funcionan tras el fallo de eliminación y la eliminación se completa en el reintento.
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_r4369224751, src/node/services/daytona/daytonaSandboxes.ts:258).
Problem
DaytonaSandboxes.deleteSandbox revokes Xum's SSH token and removes the sandbox's host block before it calls DELETE /sandbox/{id}, because Daytona refuses to revoke a token of a sandbox that no longer exists. When the delete fails with a transient error, the workspace is kept so the removal can be retried, but its alias no longer has a host block. The retry's SSH checks then fail with a hostname error until something mints access again.
Proposed fix
When client.deleteSandbox throws (other than 404), restore SSH access before rethrowing (ensureSshAccess), or have the removal path call ensureReady before its SSH checks. Add a test where the first delete fails with a 5xx and the retried removal succeeds.
Why it is deferred
#7100 runs its review loop under a P0/P1-only rule; P2 findings get a tracked follow-up. The revoke-first order predates this round.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.1k
- Forks
- 140
- Merge medio
- 3 h 23 min
- PR fusionados (30 d)
- 953
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
-
🤖 tests: lock in git status outgoing-count rename equivalence and clarify index-lock commentAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
🤖 fix: Daytona startAndWait can start a sandbox after its deadline and then report a timeoutAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
coder/xum#7358 · 4 comentarios ·
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
Issues similares
-
agent-reported area/react bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Nimblesite/SharpLsp#510 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
backend refactor
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
NIAEFEUP/tts#927 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
callstackincubator/react-native-harness#296 ·
Los mantenedores suelen responder en 1 día