🤖 perf: Daytona keepalive refreshes a shared sandbox once per workspace instead of once per sandbox
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 68/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- backend
Línea de trabajo
Start with src/node/services/daytona/daytonaReconciler.ts around line 135 and read how the 60-second sweep resolves sandbox references and checks workspace activity. Add a reconciler test for an owner and two active forks sharing one sandbox. Done when a sweep makes one last-activity call for that sandbox, with the SSH token behavior also handled once per sandbox.
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_r4353806733, src/node/services/daytona/daytonaReconciler.ts:135).
Problem
Forks and sub-agents of a Daytona workspace run as worktrees in the owner's sandbox, so several workspaces reference one sandbox. The reconciler's 60 s sweep walks workspaces, not sandboxes: every active workspace on the same sandbox sends its own POST /sandbox/{id}/last-activity (and may check its token), one after another. A large sub-agent tree multiplies control-plane calls and sweep latency for no gain, since one refresh per sandbox is enough.
Proposed fix
Group the stored references by resolved sandbox id, ask whether any workspace in the group is active, and refresh activity (and the SSH token, keyed by the stored alias) once per sandbox per sweep. Add a reconciler test with an owner and two active forks on one sandbox that expects one last-activity call.
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
- 139
- Merge medio
- 3 h 24 min
- PR fusionados (30 d)
- 954
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 78/100
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
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
scaleway/ultraviolet#7089 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
tencent-connect/dsh-qqbot#81 ·
Los mantenedores suelen responder en 1 día
-
[Bug]: Pen taps on sidebar rows start a drag and lose their clickPosiblemente ocupada @makhnatkin la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
clangd/vscode-clangd#1009 ·