🤖 fix: Daytona startAndWait can start a sandbox after its deadline and then report a timeout
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
- 83/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- backend
Línea de trabajo
Lee src/node/services/daytona/daytonaSandboxes.ts alrededor de la línea 184 y busca las pruebas de DaytonaSandboxes.startAndWait. Comprueba cómo se controla el plazo antes de la solicitud de inicio y, después, añade el caso descrito en el que el sondeo informa stopping hasta que vence el plazo y stopped después. El objetivo se cumple cuando la llamada agota el tiempo de espera sin enviar POST /sandbox/<id>/start.
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_r4369788529, src/node/services/daytona/daytonaSandboxes.ts:184).
Problem
DaytonaSandboxes.startAndWait sends the start request before it checks the deadline. When a sandbox stays in a transitional state (for example stopping) for most of the wait and the last poll after the deadline reports stopped, Xum starts the sandbox and then throws a timeout. The caller sees a failure, but the sandbox runs and bills until Daytona's auto-stop stops it (30 minutes after the last activity).
Proposed fix
Check the remaining time before the start step, and throw the timeout without a start request when the deadline has passed. Add a test with a sandbox that reports stopping until the deadline and stopped after it, and assert that no POST /sandbox/<id>/start is sent.
Why it is deferred
#7100 runs its review loop under a P0/P1-only rule; P2 findings get a tracked follow-up. Daytona's auto-stop bounds the cost of a sandbox started this way.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.1k
- Forks
- 140
- Merge medio
- 5 h 8 min
- PR fusionados (30 d)
- 952
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 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
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#7283 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
🤖 fix: refresh the runtime status chip after a turn, terminal or editor starts a stopped sandboxAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
Issues similares
-
a10y a10y-audit ai-driven-qa claude
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
linagora/twake-directory-manager#219 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
Los mantenedores suelen responder en 1 día
-
0️⃣ phase/new
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Pulse v7: buildPreferencesFromTelos() bypasses telosSectionOrFile(), renders empty on unified-TELOS installsPosiblemente ocupada @zephyr91 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
danielmiessler/LifeOS#2393 ·
Los mantenedores suelen responder en 4 días