fix: keep embedded session controls visible and handle empty memory
Publish documentation / publish (push) Successful in 34s

Cap the embedded shell at its portal container height so steering and stop controls remain accessible. Skip vector retrieval for an empty authoritative Memory archive and compute SQL-rule embeddings lazily.

Validated with 54 Memory tests, 90 frontend tests, five browser scenarios, frontend and Docker builds, and a read-only comparison against the real empty Memory archive.
This commit is contained in:
User
2026-09-14 17:15:00 +02:00
parent 49333a2d35
commit d6cdffea62
8 changed files with 241 additions and 4 deletions
@@ -0,0 +1,106 @@
# Correzione input sessione embedded e Memory vuota
## Stato
Correzioni implementate e immagini candidate costruite; **rilascio operativo non
ancora eseguito**. Il runbook `docs/operations/server-codex-handoff.md` richiede
conferma della finestra prima della ricreazione dei servizi operativi.
## Cause e correzioni
- La nuova `.thot-host` usa `100dvh`; Omics limita invece `#root` allo spazio
sotto il topbar e ne nasconde l'overflow. La prova browser riproduce controlli
che terminano a 821 px con il contenitore che termina a 782 px. La shell
embedded ora ha `max-height: 100%`, così rispetta il contenitore; il fallback
alla viewport e il contratto `--thoth-app-height` restano utilizzabili.
- Nell'installazione reale PostgreSQL contiene zero Memory Card e la collection
`psd-clinical-memory` zero punti, senza vettore sparse BM25. Il workflow
interrogava comunque embedding/Qdrant e trasformava `BM25 collection
configuration mismatch` in `memory_unavailable`, status 503. Il recupero ora
restituisce `[]` dopo aver verificato in PostgreSQL che l'archivio è vuoto.
Gli errori dell'archivio autorevole continuano a propagarsi. `memory rules`
calcola il vettore soltanto se serve e lo condivide fra le due famiglie.
Nessuna migrazione, modifica di card, indice, DWH o autenticazione è necessaria.
## Verifiche eseguite
- Riproduzione live: `tht memory search` restituisceva 503.
- Confronto delle immagini attuale/candidata, con PostgreSQL e Qdrant reali e
montaggi read-only: attuale exit 1/status 503; candidata exit 0/`[]`. La
configurazione diagnostica non contiene credenziali DWH e non interroga il DWH.
- 54 test Memory superati, 1 skipped, 2 deselected secondo la configurazione
pytest; inclusi test PostgreSQL/Qdrant reali e regressione CLI archivio vuoto.
- 90 test frontend superati: shell host, composer, creazione e gestione sessioni.
- 5 scenari Playwright superati: sessione attiva embedded a 390/1280 px con
input multilinea e apertura del dialogo di arresto; composer full dopo
navigazione amministrativa; geometria host con header/rail.
- TypeScript, build frontend, Ruff sui file Python modificati, `git diff --check`
e scansione layout superati. Entrambe le build Docker completate;
smoke della configurazione frontend superato.
- Screenshot verificati in `frontend/test-results/visual-review/`.
## Consegna candidata
Base operativa verificata e pulita: `49333a2d35664b7237c3ddc2a9f10a605dcc84ce`.
La patch `/tmp/thoth-session-memory-fix.patch` supera `git apply --check`
contro `/srv/thothii-v2/source/ThothII`.
| Immagine candidata | ID |
| --- | --- |
| `thothii-v2-core:49333a2d-session-memory-fix` | `sha256:ff4c435abd67c57e1e91e6e560dae73e67350ca499a5aedca3ffa517b9f59ee0` |
| `thothii-v2-frontend:49333a2d-session-memory-fix` | `sha256:35933317769f3e12953f3b144d51f8fc2e7e9f7c4830eba80cc626f757f5bf0d` |
Copie protette di operator.env, descriptor e override sono già in
`/srv/thothii-v2/backups/20260914-session-memory-fix` (directory 0700).
Le immagini correnti sono conservate anche con tag
`before-session-memory-fix-20260914`. Non è stato fatto un nuovo backup dei dati:
questa preparazione non ha modificato dati e non sostituisce un backup coerente
nella finestra operativa, se richiesto dal runbook di rilascio.
## Comandi risolti per la finestra da confermare
Verificare nuovamente lo stato delle sessioni e gestire quelle attive prima del
riavvio. Il seguente launcher conserva progetto, env file e ordine degli override:
```bash
thoth_fix_compose() {
sudo docker compose --project-name thothii-7f901b48fe35 \
--project-directory /srv/thothii-v2/source/ThothII \
--env-file /srv/thothii-v2/operator/operator.env \
-f /srv/thothii-v2/source/ThothII/compose.yaml \
-f /srv/thothii-v2/source/ThothII/deploy/compose.server.yaml \
-f /srv/thothii-v2/source/ThothII/deploy/compose.git-ssh.yaml \
-f /srv/thothii-v2/operator/compose.portal-upstream.yaml \
-f /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/generated/compose.models.yaml "$@"
}
thoth_fix_compose exec -T core node /app/backend/dist/operator-command.js maintenance-activate
thoth_fix_compose exec -T core node /app/backend/dist/operator-command.js maintenance-status
sudo git -C /srv/thothii-v2/source/ThothII apply /tmp/thoth-session-memory-fix.patch
```
Dopo gestione delle sessioni e backup nella finestra, aggiornare esclusivamente
`THTII_RELEASE_IMAGE_TAG` in `/srv/thothii-v2/operator/operator.env` al valore
`49333a2d-session-memory-fix`, preservando gli altri valori e i permessi.
Quindi:
```bash
thoth_fix_compose up -d --no-deps --no-build core frontend
sudo docker exec omics_portal-nginx-1 nginx -t
sudo docker exec omics_portal-nginx-1 nginx -s reload
sudo tht --installation /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/thothii-installation.yaml status
sudo tht --installation /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/thothii-installation.yaml doctor --json
```
Attendere il TTL di 30 secondi del manifest Django, verificare asset/config e
Memory; provare input/arresto nel portale prima della riapertura:
```bash
thoth_fix_compose exec -T core node /app/backend/dist/operator-command.js maintenance-deactivate
```
Rollback applicativo: ripristinare l'operator.env protetto, ricreare solo
core/frontend con lo stesso launcher, verificare e ricaricare nginx. Per riallineare
anche i sorgenti usare `git apply --reverse --check` e poi `git apply --reverse`
sulla sola patch preparata, senza reset di altre modifiche. Non occorre ripristinare
PostgreSQL o indici per un rollback di queste due correzioni.