A failed update_addons_all left one option, « [1] to redo the command » —
useless against the failure that actually causes it, since redoing an upgrade
whose COW copy has drifted fails again identically. The prompt now offers to
run reset_stale_cow_views on the database concerned:
[1] to redo the command
[2] Check the COW views that drifted (technolibre_…_upgrade_15)
Choosing [2] runs the checker and comes back to the same prompt, so the usual
sequence — look, repair, redo — happens without leaving the migration.
The database is read from the failed command itself, since the executor is not
told which one it is. Three forms are recognised: « -d <db> », « --database
<db> », and the positional argument of the addons scripts. No database found,
no [2] offered — « make format » gets the old prompt unchanged.
The option only ever REPORTS. Resetting a copy can erase a real customisation,
so it stays a separate deliberate command, printed with the exact line to run
and a reminder to read the diff first.
Verified: the six command forms parsed correctly (and two that hold no
database at all), [2] invoking the tool then re-offering the choice, no [2] on
a command without a database, and the whole chain against the real
_upgrade_15, where it prints the two drifted copies followed by the reset
line.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mathieu Benoit
2997dfeb26