1.3b Step | SetupCacheDir

Owns <odoo_home>/.cache, so the rollback can remove it. It lives in src/steps/setup_cache_dir.rs. Born in R6-hotfix-3 to close the second half of A-R5-3, and with it a change of question that matters beyond this step.

---

The problem: the home is the customer's, the caches are ours

/opt/odoo is the odoo user's $HOME. If it already exists, the installer marks it Preexisting and never empties it — rightly so: it may contain the customer's things. But plenty of programs run inside that home on our behalf (pip, odoo-bin, the Odoo service), and they all write into $HOME/.cache, which on Linux is where caches go.

R6 had closed the biggest case by moving pip's cache into the venv (--cache-dir). It was not enough. The first installation that reached the end in CI — 23 steps, Odoo answering, a complete rollback — found this again:

✖  /opt/odoo still contains: .cache

With a whole installation running, odoo-bin -i base and the service run too: fontconfig's font scan, pip's version selfcheck (which up to 23 ignores --cache-dir and writes into the user cache anyway), and whoever else tomorrow.

The rollback said “nothing left behind”, and it was telling the truth. No undo had failed: .cache simply belonged to no step, so it was not in the manifest. The report is honest; the hole was upstream.

---

The fix: change the question

Chasing the producers one by one is a losing battle — they are third-party programs and their behaviour changes between versions. This step does not ask who wrote into .cache, but whose it is:

Phase	Behaviour
snapshot	does <odoo_home>/.cache already exist? → Preexisting. Otherwise record that we will create it
run	Preexisting → no-op. Otherwise mkdir -p as the odoo user → CreatedByUs
undo	CreatedByUs → rm -rf. Anything else → NO-OP

If we create it, it is ours and the rollback removes it; if it was already there, it is the customer's and stays untouched. The number of producers becomes irrelevant — and that is the property that makes this a final fix rather than another lap of the chase.

Creation happens as the odoo user and not as root: the one who will write there is that user, and a root-owned directory would force it to open another one somewhere else.

---

One gate only, unlike the filestore

Same mechanics as 1.12b SetupDataDir — owning a branch inside somebody else's home — but a different gate: the filestore holds application data, so its removal is also conditional on owning the database. A cache is not: it is regenerable by definition, it belongs to no data, and the only question that matters is who created the directory.

The two steps share the two delicate pieces, in steps:::

• highest_missing_level — the first non-existent level going down from the home towards the target: the root of what mkdir -p will create, and the only thing the undo can remove without touching somebody else's things;
• remove_created_root — the rm -rf with the perimeter safety net: the target comes from the persisted snapshot, i.e. from disk, and a corrupted state must not be able to become a deletion elsewhere. It must be a strict descendant of the home, otherwise it is logged and nothing is touched.

---

The ordering, which here is an advantage

The step sits early in the sequence, right after 1.3 SetupLogDir and before anything runs as the odoo user. It has to: otherwise the snapshot would find a “pre-existing” .cache that is nothing of the sort.

And since undos run backwards, early here means late there: the cache is removed after the service has been stopped, the venv deleted and the sources removed — that is, after every possible writer has stopped writing. It is the opposite of the compromise SetupDataDir has to accept (its undo runs before the dropdb, and there it is unavoidable), and it is checked by a test on the canonical sequence: if anyone moved this step further down, that test fails.

---

Design notes

• dry_run: neither mkdir nor rm -rf, only logs.
• Tests (tests/setup_cache_dir.rs): ours vs the customer's, a verdict that survives the round trip through disk (without rehydrate the cache would stay), the perimeter with hostile paths, an inert dry-run, and the position in the sequence. Plus setup-cache-dir in tests/rehydrate.rs's CHAIN, which checks the equivalence between the live undo and the rehydrated one.