Preset setup can send the same component deploy from two browser contexts

Abierto
  • ¿Algo no está bien?
#2,056 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend, distributed-systems

Línea de trabajo

Read src/features/clusters/presets/runPresetSetup.ts, presetDeployMarks.ts, and applications/DESIGN.md, then follow how Cluster.preset reaches useOwedPresetSetup and recorded. The proposed fix is to move preset setup into central-manager provisioning and leave Studio to report status with a manual fallback; confirm the central-manager dependency and define how setup status is reported before implementation.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

blocked

Deferred from review of #2031.

Problem

Preset setup (src/features/clusters/presets/runPresetSetup.ts) protects a deploy in two ways, and both only work inside one browser context:

  • The deploy marks (presetDeployMarks.ts). Setup writes an unconfirmed mark to localStorage (Studio:PresetSetupDeploys:<clusterId>) before it sends a component deploy, and keeps it when the outcome is unknown. That mark is what stops a Retry from sending the same deploy again.
  • The per-cluster Web Lock (navigator.locks.request('Studio:PresetSetup:<clusterId>')). It serializes runs across tabs, and the in-memory inFlight map does the same when the browser has no Web Locks.

A second browser, or a private window, sees neither of them. In that context runOnce finds no mark, and if the component is not listed on the node it reached yet, it sends the deploy itself. The replicated hdb_deployment record is only read (everyNodeHasIt) for a component that is already listed. So the window that matters is a deploy that is in flight, or unconfirmed, but has not appeared yet. Two cases:

  1. Two admins, or one admin in two browser contexts, run setup for the same new cluster at the same time, and both send the same preset component deploy.
  2. A deploy that one context marked unconfirmed (the stream was inconclusive, the write went unanswered, or the tab closed) gets sent again from another context while that first install is still unresolved. This is the case applications/DESIGN.md ("A live deploy is sent once") exists to prevent.

runPresetSetup's doc comment already names this limit. This issue tracks closing it.

When it can trigger

The only way a second browser learns that a cluster still owes setup is Cluster.preset from central-manager (useOwedPresetSetup → recorded). The pending-setup record is per-browser localStorage. Central-manager starts storing the preset with HarperFast/central-manager#1047, which is still open, so the hazard goes live when that lands. The code lives only on #2031, which has not been released.

Proposed fix

The review named the do-less fix: have central-manager run setup during provisioning, from the Cluster.preset it stores (central-manager#1047). Studio then never deploys preset components from the browser, so there is no browser-local state to share and every cross-browser hazard goes away. Studio's role shrinks to reporting setup status, plus a manual fallback for central managers that don't run setup.

Review-Deferral: b9160a232bb2fc08 severity=minor category=concurrency

Lenguaje dominante
TypeScript
Estrellas
5
Forks
4
Merge medio
1 d 20 h
PR fusionados (30 d)
140

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de HarperFast/studio

Todos los issues de HarperFast/studio

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.