Remaining edge paths for an instance with no address

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

Línea de trabajo

Start with src/features/auth/ClusterInstanceSignIn.tsx, src/features/instance/instanceLayoutRoute.ts, src/features/cluster/Instances.tsx, useInstanceMenuItems.tsx, and ClusterHome.tsx; trace the URL helper and byInstanceFqdnThenPort mentioned in the issue. Check the sign-in, remembered connection, URL display and copy, sorting, and Disconnect paths for address-less instances, while preserving Local Studio's fallback. Done when each path handles missing or invalid addresses consistently and the existing behavior is checked.

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

Descripción

Summary

Some edge paths around an instance Studio has no address for are still unhandled. Both predate the #2020 fix and were found by code trace during its review; neither is observed in production.

1. The sign-in health probe fires before it knows where to go

ClusterInstanceSignIn (src/features/auth/ClusterInstanceSignIn.tsx) runs getInstanceHealthQueryOptions whenever the cluster isn't terminated. Two states send that GET /health somewhere unintended:

  • While the cluster query is still loading, operationsUrl is null, so getInstanceClient falls back to a stored sign-in URL or the page's own origin.
  • When the route's instanceId isn't in cluster.instances, the memo takes the cluster branch and probes the cluster's URL instead.

A plain !!operationsUrl gate would break Local Studio, which has no cluster and relies on the same fallback, so the gate needs to keep that case (for example isLocalStudio || !!operationsUrl).

2. A remembered sign-in reopens an instance that has lost its address

On reload, checkClusterInstanceAuthenticationBeforeLoad (src/features/instance/instanceLayoutRoute.ts) resumes a remembered connection before it reaches the Fabric Connect attempt that now refuses an address-less instance. So an instance that was signed in while it had an FQDN still opens after central manager stops listing one, through the stored URL or the proxy, while its row on the Instances list shows —.

3. Raw FQDN checks disagree with the URL helper

getOperationsUrlForInstance returns null for an FQDN that new URL rejects (whitespace-only, a bare https://), but the self-hosted URL column (src/features/cluster/Instances.tsx), the menu's copy actions (useInstanceMenuItems.tsx) and byInstanceFqdnThenPort still test the raw field for truthiness. Such a value gets a garbled URL cell, copy actions, and a sort position ahead of real addresses. Hypothetical (central manager has not been seen to send one) and cosmetic; nothing throws. Fix by normalising the address once.

4. Self-hosted Disconnect with an address-less first instance

ClusterHome.tsx's Disconnect passes getOperationsUrlForInstance(firstInstance), which can now be null, so getInstanceClient falls back to the stored sign-in URL. A connected instance always has one, so this looks correct; recorded so it gets checked rather than assumed.

Related: #2021 (cluster sign-out can't clear such an instance).

Review-Deferral: b326cc50556fa97a severity=nit category=correctness
Review-Deferral: aa30a9bb10d1ee30 severity=nit category=correctness
Review-Deferral: d4ecec465c740ecf severity=nit category=correctness
Review-Deferral: 1e45c35cbd41a55f severity=nit category=reliability

🤖 Generated by Claude Code (Claude Opus 5.5); posted via @dawsontoth.

Lenguaje dominante
TypeScript
Estrellas
5
Forks
4
Merge medio
1 d 19 h
PR fusionados (30 d)
144

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.