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

Abierto
  • ¿Algo no está bien?
#2,057 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
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
65/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
react, typescript
Área
frontend, testing

Línea de trabajo

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.

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

Descripción

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

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.