Cluster form accepts a restored custom region that has since been deactivated

Đang mở
  • Có gì không ổn?
#2,057 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ó
3/5
Thời gian dự kiến
Nửa ngày
Mức phù hợp với người mới
65/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
react, typescript
Lĩnh vực
frontend, testing

Hướng nghiên cứu

Start in src/features/clusters/upsert/ClusterForm.tsx, especially the organization-region branch of refineZod, and review preexistingOrganizationRegionIds to decide how edits to clusters already using an inactive region should validate. Then read ClusterForm.regions.test.tsx and add coverage for a restored draft and a failed-cluster retry with an inactive organization region. Done means the inactive restored value is rejected unless the chosen rule allows an existing deployment to remain, with both cases covered.

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

Mô tả

Deferred from review of #2031. This is pre-existing: the code below is on stage and has shipped since v2.204.0, and #2031 does not change it.

Problem

The cluster form's region validation (refineZod in ClusterForm.tsx) checks whether regionLookup.get(regionId) resolves. It never reads ResolvedRegion.active. Meanwhile buildRegionLookup puts every organization region into the lookup, inactive ones included (active: region.active !== false).

The picker hides inactive regions from new choices. RegionFormInputs lists an inactive organization region only when it is already that row's value, with an "Inactive" badge, and "Add a region" in ClusterRegions.tsx skips inactive ones. But a value restored into the form never goes through the picker:

  • A saved draft. migrateDraftRegionPlans keeps an id-keyed entry as it is.
  • A retry of a failed cluster. buildRegionPlanDefaults keeps every id that the lookup resolves.

If the organization region was deactivated after the draft was saved or the create failed, the id still resolves. The refinement then runs its organization-region checks (datacenters on the provider, staff placement, quantity, minimum instances), none of which is about active, and passes. The submit loop (L520-L531) then sends the inactive region's id in plans. The only sign the user gets is the badge on the row.

Who it reaches: a user without the staff custom-region permission already hits "Custom regions can only be placed by Harper staff." for any organization region the cluster does not already deploy. So for them the gap is limited to an inactive region that is already on the cluster. Staff with cluster:create / cluster:update reach it for any restored region.

What is already handled, and out of scope here:

  • An organization region that is gone from the organization's list misses the lookup, and the refinement reports "This region is no longer available."
  • Catalog regions: central-manager's GET /Region/ already leaves out inactive catalog regions (isRegionReadableByOrg), so a retired catalog id misses the lookup the same way. syncRegionSelectionsWithPossibleRegions either remaps it or clears it to '', and an empty id fails the schema's "Please select a region."

When it can trigger

Today it cannot happen against central-manager main: its GET /OrganizationRegion/ answers null (custom regions are not served yet), and Studio reads that as "no organization regions". It becomes reachable once custom regions ship and a region is deactivated between a draft or failed create and the retry. This issue does not cover what central-manager does when it receives an inactive organization region.

Proposed fix

In the organization-region branch of refineZod, add an issue on regionPlans.${i}.regionId when !region.active, with a message like "This custom region is inactive. Choose another region." One design choice is needed: should an edit that keeps an inactive region the cluster already deploys (preexistingOrganizationRegionIds) still pass? Blocking it would stop an existing cluster from being edited at all. Exempting it matches how the staff-placement check already treats existing regions. Add tests in ClusterForm.regions.test.tsx for both a restored draft and a failed-cluster retry carrying an active: false organization region.

Review-Deferral: 830fa068f7c84900 severity=minor category=correctness

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.