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

Đang mở
  • Có gì không ổn?
#2,056 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend, distributed-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
TypeScript
Star
5
Fork
4
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
65

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của HarperFast/studio

Tất cả issue của HarperFast/studio

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.