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

オープン
  • 何か問題がありますか？
#2,056 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
backend, distributed-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
5
フォーク
4
平均マージ
1日 20時間
マージ済み PR（30日）
140

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

HarperFast/studio のほかの issue

HarperFast/studio の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。