[GH-ISSUE #4581] [Bug] Uninstall keeps only the pre-setup backup and tells users to restore it #2378

New issue

Closed

opened 2026-10-17 21:03:55 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-17 21:03:55 +00:00

Owner

Originally created by @Adolanium on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4581

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

After an earlier rea setup, rea uninstall makes no copy of a client configuration before editing it. .rea.backup already exists with the bytes from before setup, and uninstall treats EEXIST on that copy as success.

If the edit fails and the restore also fails, the uninstall item says:

Configuration could not be updated or restored. Restore its .rea.backup manually, then rerun uninstall.

That file is the pre-setup configuration. Restoring it drops every change made since setup, including user edits. The update-failure message points to the same file.

Setup's readback-failure message has the same wording, Repair the configuration file or restore its .rea.backup, even when setup used a .rea.backup.<sha256>.recovery copy.

Reproduction

Create a client configuration such as {"keep":"before setup"} for Cursor.
Run setup so it registers REA. .rea.backup now holds {"keep":"before setup"}.
Edit the configuration so keep is "edited after setup", leaving the REA entry in place.
Run uninstall with a configuration write that fails twice (the update and the restore).
Observe the message names .rea.backup, which holds the pre-setup bytes. No file holds the edited configuration.

Steps 4 and 5 were run through systemUninstallHost(root, fileSystem).removeClient(...) with an injected writeText that throws.

Expected behavior

docs/installation.md says setup and uninstall retain the first .rea.backup, and that setup preserves a verified .rea.backup.<sha256>.recovery copy of the current bytes when the first snapshot differs. Uninstall should do the same before it edits the file, and its failure messages should name the backup that holds the bytes from just before the edit.

Impact and scope

Affects any client configuration that was changed after the first setup, which includes every rerun of setup that updated the REA entry. The loss only happens when the uninstall edit fails and the user follows the printed restore instruction. A successful uninstall does not lose data, but it also leaves no snapshot of the configuration as it was before uninstall.

REA version

6.5.0, revision 8ab502439

Runtime and platform

Node 24 on Windows 11. The backup logic is platform-independent.

Target and artifact context

No analysis target. A synthetic Cursor mcp.json in a temporary directory.

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Configuration could not be updated or restored. Restore its .rea.backup manually, then rerun uninstall.

.rea.backup contents after the run: {"keep":"before setup"}. The configuration before uninstall had "keep": "edited after setup".

Typed outcome or recovery expected

A verified <config>.rea.backup.<sha256>.recovery file holding the pre-uninstall bytes, and a failure item whose detail names that path.

Analysis or suspected cause

Source-derived. removeClient in src/application/Uninstall.ts copies to the fixed ${configPath}.rea.backup path and ignores EEXIST. It does not use selectCurrentRecoveryBackup from src/application/SetupRecoveryBackup.ts, which setup's persistClientConfiguration uses to pick and verify a recovery path. The failure strings hardcode .rea.backup. failedConfigurationMessage in src/application/SetupClients.ts hardcodes it for readback too, and the readback result has no backupPath.

Additional context

Fix is in https://github.com/morluto/rea/pull/4580.

Originally created by @Adolanium on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4581 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior After an earlier `rea setup`, `rea uninstall` makes no copy of a client configuration before editing it. `.rea.backup` already exists with the bytes from before setup, and uninstall treats `EEXIST` on that copy as success. If the edit fails and the restore also fails, the uninstall item says: `Configuration could not be updated or restored. Restore its .rea.backup manually, then rerun uninstall.` That file is the pre-setup configuration. Restoring it drops every change made since setup, including user edits. The update-failure message points to the same file. Setup's readback-failure message has the same wording, `Repair the configuration file or restore its .rea.backup`, even when setup used a `.rea.backup.<sha256>.recovery` copy. ### Reproduction 1. Create a client configuration such as `{"keep":"before setup"}` for Cursor. 2. Run setup so it registers REA. `.rea.backup` now holds `{"keep":"before setup"}`. 3. Edit the configuration so `keep` is `"edited after setup"`, leaving the REA entry in place. 4. Run uninstall with a configuration write that fails twice (the update and the restore). 5. Observe the message names `.rea.backup`, which holds the pre-setup bytes. No file holds the edited configuration. Steps 4 and 5 were run through `systemUninstallHost(root, fileSystem).removeClient(...)` with an injected `writeText` that throws. ### Expected behavior `docs/installation.md` says setup and uninstall retain the first `.rea.backup`, and that setup preserves a verified `.rea.backup.<sha256>.recovery` copy of the current bytes when the first snapshot differs. Uninstall should do the same before it edits the file, and its failure messages should name the backup that holds the bytes from just before the edit. ### Impact and scope Affects any client configuration that was changed after the first setup, which includes every rerun of setup that updated the REA entry. The loss only happens when the uninstall edit fails and the user follows the printed restore instruction. A successful uninstall does not lose data, but it also leaves no snapshot of the configuration as it was before uninstall. ### REA version 6.5.0, revision `8ab502439` ### Runtime and platform Node 24 on Windows 11. The backup logic is platform-independent. ### Target and artifact context No analysis target. A synthetic Cursor `mcp.json` in a temporary directory. ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence `Configuration could not be updated or restored. Restore its .rea.backup manually, then rerun uninstall.` `.rea.backup` contents after the run: `{"keep":"before setup"}`. The configuration before uninstall had `"keep": "edited after setup"`. ### Typed outcome or recovery expected A verified `<config>.rea.backup.<sha256>.recovery` file holding the pre-uninstall bytes, and a failure item whose detail names that path. ### Analysis or suspected cause Source-derived. `removeClient` in `src/application/Uninstall.ts` copies to the fixed `${configPath}.rea.backup` path and ignores `EEXIST`. It does not use `selectCurrentRecoveryBackup` from `src/application/SetupRecoveryBackup.ts`, which setup's `persistClientConfiguration` uses to pick and verify a recovery path. The failure strings hardcode `.rea.backup`. `failedConfigurationMessage` in `src/application/SetupClients.ts` hardcodes it for `readback` too, and the `readback` result has no `backupPath`. ### Additional context Fix is in https://github.com/morluto/rea/pull/4580.

bsakaguchi referenced this issue

2026-10-31 00:29:41 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi closed this issue

2026-10-31 00:33:15 +00:00