🤖 fix: a Daytona connection test started before a settings save can show the old key as connected
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
- 79/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- react, typescript
Línea de trabajo
Empieza con src/browser/features/Settings/Sections/DaytonaSettingsForms.tsx y la discusión de revisión anterior enlazada en el issue. Sigue cómo runTest, settle, resetTest y guardar o eliminar gestionan una prueba en curso, y añade la prueba de UI descrita: inicia una prueba, guarda una clave nueva y resuelve correctamente la prueba anterior. El trabajo estará terminado cuando el resultado obsoleto no muestre «Connected»; elige cualquiera de las soluciones propuestas.
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_r4354065080, src/browser/features/Settings/Sections/DaytonaSettingsForms.tsx:89).
Problem
In Settings > Daytona, a connection test result is tagged with the settings load generation (loads) it ran under. Saving or removing the API key calls resetTest(), which clears the current result but neither cancels the in-flight daytona.testConnection() call nor bumps loads (that happens only after the reload). Save stays enabled while a test runs. So a test started with the old key can finish after the save and show "Connected" for the previous credentials, even when the newly saved key is invalid.
Proposed fix
Either invalidate the test generation on every save and remove (a local counter that runTest captures and settle compares), or disable Save and Remove while a test is running. Add a UI test: start a test, save a new key, resolve the old test as ok, and expect no "Connected" state.
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 55 min
- PR fusionados (30 d)
- 897
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 82/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 76/100
coder/xum#7121 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
🤖 fix: stream-error card header actions reach 2.6px into the card padding in a 170px VS Code sidebarAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 1 día
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
db-ux-design-system/core-web#8613 ·
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
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
foxglove/mcap#1907 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug internal-plugin pr-welcome upstream
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dsh-tauri-desk/deepseek-harness-desktop#1225 · 1 comentario ·
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
unjs/unhead#1027 · 1 reacción ·
Los mantenedores suelen responder en 1 día