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

Aperta
  • Qualcosa non va?
#2,057 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
65/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
react, typescript
Ambito
frontend, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
TypeScript
Stelle
5
Fork
4
Merge medio
1g 20h
PR unite (30g)
140

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/studio

Tutte le issue di HarperFast/studio

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.