1.3b Step | SetupCacheDir

Possiede <odoo_home>/.cache, così il rollback può rimuoverla. Vive in src/steps/setup_cache_dir.rs. Nato in R6-hotfix-3 per chiudere la seconda metà di A-R5-3, e con esso un cambio di domanda che vale oltre questo step.

---

Il problema: la home è del cliente, le cache sono nostre

/opt/odoo è l'$HOME dell'utente odoo. Se esiste già, l'installer la marca Preexisting e non la svuota mai — giustamente: può contenere roba del cliente. Ma dentro quella home girano parecchi programmi per conto nostro (pip, odoo-bin, il servizio Odoo), e tutti scrivono in $HOME/.cache, che su Linux è dove le cache vanno a finire.

R6 aveva chiuso il caso più grosso spostando la cache di pip dentro il venv (--cache-dir). Non bastava. La prima installazione arrivata in fondo in CI — 23 step, Odoo che risponde, rollback completo — ha trovato di nuovo:

✖  /opt/odoo contiene residui: .cache

Con l'installazione intera girano anche odoo-bin -i base e il servizio: lo scan dei font di fontconfig, il selfcheck delle versioni di pip (che fino alla 23 ignora --cache-dir e scrive comunque nella cache utente), e chiunque altro domani.

Il rollback diceva "nessun residuo", e diceva il vero. Nessun undo era fallito: .cache semplicemente non apparteneva a nessuno step, quindi non era nel manifesto. Il report è onesto; il buco era a monte.

---

Il fix: cambiare domanda

Inseguire i produttori uno per uno è una battaglia che si perde — sono programmi di terzi e cambiano comportamento fra versioni. Questo step non chiede chi ha scritto in .cache, ma di chi è:

Fase	Comportamento
snapshot	<odoo_home>/.cache esiste già? → Preexisting. Altrimenti registra che la creeremo noi
run	Preexisting → no-op. Altrimenti mkdir -p come utente odoo → CreatedByUs
undo	CreatedByUs → rm -rf. Altro → NO-OP

Se la creiamo noi è nostra e il rollback la rimuove; se c'era già è del cliente e non si tocca. Il numero di produttori diventa irrilevante — ed è la proprietà che rende il fix definitivo invece di un altro giro di rincorsa.

La creazione avviene come utente odoo e non come root: chi ci scriverà è lui, e una directory di root lo costringerebbe ad aprirne un'altra da qualche altra parte.

---

Un gate solo, a differenza del filestore

Stessa meccanica di 1.12b SetupDataDir — possedere un ramo dentro la home altrui — ma gate diverso: il filestore contiene dati applicativi, e la sua rimozione è subordinata anche alla proprietà del database. Una cache no: è rigenerabile per definizione, non appartiene a nessun dato, e l'unica domanda che conta è chi ha creato la directory.

I due step condividono i due pezzi delicati, in steps:::

• highest_missing_level — il primo livello inesistente scendendo dalla home verso il target: la radice di ciò che il mkdir -p creerà, e l'unica cosa che l'undo può rimuovere senza toccare roba di altri;
• remove_created_root — il rm -rf con la rete sul perimetro: il target arriva dallo snapshot persistito, cioè dal disco, e uno stato corrotto non deve poter diventare una cancellazione altrove. Dev'essere un discendente stretto della home, altrimenti si logga e non si tocca nulla.

---

L'ordine, che qui è un vantaggio

Lo step sta presto nella sequenza, subito dopo 1.3 SetupLogDir e prima che qualunque cosa giri come utente odoo. Deve: altrimenti lo snapshot troverebbe una .cache "preesistente" che preesistente non è.

E poiché gli undo girano al contrario, presto qui significa tardi là: la cache viene rimossa dopo che il servizio è stato fermato, il venv cancellato e i sorgenti rimossi — cioè dopo che ogni possibile scrittore ha smesso di scrivere. È l'opposto del compromesso che SetupDataDir deve accettare (il suo undo gira prima del dropdb, e lì non è evitabile), ed è verificato da un test sulla sequenza canonica: se qualcuno spostasse questo step più in basso, cade.

---

Note di design

• dry_run: né mkdir né rm -rf, solo log.
• Test (tests/setup_cache_dir.rs): proprietà nostra vs del cliente, verdetto che attraversa il disco (senza rehydrate la cache resterebbe), perimetro con path ostili, dry-run inerte, e l'ordine nella sequenza. Più setup-cache-dir nella CHAIN di tests/rehydrate.rs, che verifica l'equivalenza fra undo live e undo reidratato.