Desplegado en staging, el "montar el control de capas una sola vez" resultó
peor que el bug que arreglaba: /fires seguía en gris Y además la portada y
/zones —que sí pintaban— se quedaron también sin teselas. Con la clave real, el
control acaba montándose después de que el mapa ya esté montado, y entonces no
se le añade ninguna capa base. O sea que la carrera no se arregla retrasando el
montaje: solo cambia de sitio.
Staging revertido a la imagen anterior y comprobado que vuelve a estar como
estaba (portada 36 teselas, /zones 18, /fires 0).
Se conserva todo lo aprendido, que es lo que vale: el bug se reproduce en local
poniendo una clave de Google en settings-ci.json (15 teselas sin clave, 0 con
ella), NO es cosa del navegador sin pantalla, y e2e/tests/fires-map.spec.js lo
deja como test.fixme para que aparezca en cada ejecución. El arreglo bueno pasa
por decidir el conjunto de capas base ANTES de montar el mapa.
Síntoma: en staging /fires no pintaba teselas ni fuegos, no creaba la
suscripción `activefiresmyloc` y se quedaba con "Actualizando…" para siempre. Se
había atribuido a que el navegador de las pruebas no compone; no era eso. El
mismo navegador pinta la portada, y pinta /fires perfectamente contra un
servidor local.
La diferencia era la clave de Google. `DefMapLayers` montaba el control de capas
con dos capas base (OSM color y gris) y, cuando `Gkeys` resolvía la clave,
volvía a renderizar añadiendo tres capas de Google. En esa segunda pasada
react-leaflet se dejaba por el camino la capa base marcada, y el mapa se quedaba
sin ninguna. En desarrollo no hay clave, así que la segunda pasada no añadía
nada y el bug no se veía nunca.
El control se monta ahora una sola vez, con la lista de capas ya cerrada, y con
un tope de 5 s por si el script de Google no llega: las capas de Google son un
extra, el mapa tiene que salir igual.
Reproducido en local poniendo una clave falsa en settings-ci.json (0 teselas
antes del arreglo, 15 después). Esa clave falsa se queda ahí a propósito, para
que la suite e2e recorra el mismo camino que staging y producción, y
e2e/tests/fires-map.spec.js lo fija: teselas, una única capa base marcada,
suscripción por viewport, y que no se quede en "Actualizando…".
16 tests e2e en verde.
Playwright under e2e/, its own npm project so Meteor never sees the dependency
(.meteorignore keeps the directory out of the bundle — a config file at the app
root is otherwise eagerly loaded into the server and crashes it).
Covers what the phase asked for: sign up / log in, creating a zone from the map
and watching the union get painted on /subscriptions and /zones, removing it
again, commenting on a fire, and switching language. The zone spec is the flow
that froze staging on 2026-07-30 — it passes only if the server is still
answering DDP while the union is recomputed.
docker-compose.e2e.yml is a throwaway stack (Mongo on tmpfs, no named volume) so
the destructive seeds cannot be pointed at anything real by accident;
playwright.config.js refuses to start against the staging or production domains.
i18n.spec.js leaves a test.fixme on a real bug found while writing it: the
language chosen in the profile does not survive a page reload.
