Skip to content

Fix/preview de la sala equivocada - #32

Merged
ErickUser1 merged 3 commits into
mainfrom
fix/preview-de-la-sala-equivocada
Aug 13, 2026
Merged

Fix/preview de la sala equivocada#32
ErickUser1 merged 3 commits into
mainfrom
fix/preview-de-la-sala-equivocada

Conversation

@ErickUser1

Copy link
Copy Markdown
Owner

No description provided.

ErickHub192 and others added 3 commits August 12, 2026 19:22
Al volver a una sala visitada antes, el preview salia en negro con un "Invalid
hook call" y dos copias de React. No era el proyecto: eran modulos de OTRA sala.

La cookie que dice de que sala son los modulos es una sola para todo el
navegador, asi que entrar a una segunda sala la sobrescribe. Al volver a la
primera, su HTML salia del cache del navegador (un 304 que ni llegaba al
proxy), la cookie se quedaba apuntando a la otra, y los modulos que Vite pide
desde la raiz (`/src/main.tsx`, cuyo Referer encadena a otro modulo y ya no
trae el roomId) se resolvian contra el proyecto equivocado.

Por eso solo pasaba con dos o mas salas, y de forma intermitente: dependia de
que hubiera en cache.

Ahora la pagina de entrada de la sala se pide siempre fresca (se le quitan las
cabeceras de revalidacion al ir, y el cache y el ETag al volver), asi la cookie
queda correcta ANTES de que se pidan los modulos. Los archivos del proyecto
siguen cacheando normal: ahi el 304 es lo que se quiere.

Es agnostico: no toca como se levanta ningun stack, solo el HTML que el proxy
ya servia. El demo sube a 39 comprobaciones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
En el log de una sala salia Vite avisando "Port 5173 is in use, trying another
one" y quedaban DOS dev servers, uno en cada puerto. El proxy apunta a uno
solo, asi que la mitad de las peticiones le pegaban al que no era: preview en
blanco, o modulos servidos por un Vite distinto al que sirvio el HTML.

Dos caminos piden el preview casi a la vez: `wakeRoom` al despertar la sala y
el `join` de quien entra. La bandera `previewBooting` no los frenaba porque
entre leerla y ponerla hay un `await detectLaunch` que toca disco: los dos la
leian en false y los dos arrancaban.

Ahora se serializa por sala con el mismo KeyedMutex que ya protege los
contenedores. Salas distintas siguen arrancando en paralelo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
En el log salia la misma sala arrancando tres dev servers seguidos (5173, 5174,
5175), y entre uno y otro un "contenedor listo" nuevo: no era el preview
repitiendose, era la SALA despertando tres veces.

Entrar dispara varias peticiones casi a la vez (el join por socket, el
historial, el mapa del back). `wakeRoom` comprobaba el Map y luego hacia varios
`await` a disco y a la BD antes de registrar la sala, asi que las tres la veian
ausente, las tres construian una sala nueva, y cada una arrancaba su preview.
Cada `rooms.set` pisaba al anterior, y la sala que quedaba en memoria no era la
del dev server al que apuntaba el proxy: preview en blanco.

Mismo patron que ya se uso para los contenedores y para el arranque del
preview: KeyedMutex por sala, y volver a mirar el Map con el turno ya tomado.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ErickUser1
ErickUser1 merged commit beac660 into main Aug 13, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants