[BUG] Git vault sync removed all tracked stores after v24 migration / cross-device sync

[BUG] Git vault sync removed all tracked stores after v24 migration / cross-device sync

Environment

• XPipe: v24.x / v24.1.1

• Vault sync: Git repository hosted on GitHub

• Vault setting: Encrypt all vault data enabled

• Clients:

  • Ubuntu
  • Windows

• Same Git vault synchronized between both clients

• Vault migrated from the v23.x format to v24.x

Summary

After upgrading/migrating the vault to XPipe v24 and using the same Git-synchronized vault between Ubuntu and Windows, XPipe eventually removed all synchronized connection stores from the Git repository.

This was not only a UI issue or a failure to load the entries.

The Git history contained explicit commits generated for every synchronized store, for example:

Remove <store-uuid-1>
Remove <store-uuid-2>
Remove <store-uuid-3>
...
Remove <store-uuid-N>

Each of these commits deleted:

stores/<UUID>/entry.json
stores/<UUID>/store.json

Before this sequence, the Git repository contained:

21 stores/*/entry.json
21 stores/*/store.json

After the removal sequence, none of those synchronized stores were tracked remotely anymore.

Some corresponding local vault files still existed in the XPipe storage directory, but they were no longer tracked by Git and the affected connections were no longer available as expected through XPipe.

A small number of unrelated connections had been intentionally deleted before this event. Those intentional deletions are not part of this bug.

Recovery

I was able to recover the vault using Git:

1. Closed XPipe on both Ubuntu and Windows.
2. Identified the commit immediately before the first unintended Remove <UUID> commit.
3. Reset master to that commit.
4. Force-pushed the recovered branch to GitHub.
5. Verified that the remote Git tree again contained:

21 stores/*/entry.json
21 stores/*/store.json

1. Started XPipe on Ubuntu.

2. XPipe created only normal metadata updates such as:

   • vaultversion
   • preferences.json
   • README.md

3. No store deletion commits were generated.

4. Reset the Windows clone to the restored remote branch.

5. Started XPipe on Windows.

6. No new store deletion commits were generated.

7. The remote Git repository still contained all 21 synchronized stores.

This suggests that the Git repository itself was recoverable and that some vault migration/synchronization state transition caused XPipe to interpret existing synchronized stores as removed.

Possibly related issues

This might be related to #907 because that issue also involves the v23 → v24 migration and Encrypt all vault data.

However, this case seems different because the stores had already been successfully migrated and committed to Git. XPipe subsequently generated explicit Remove <UUID> commits for every synchronized store.

#334 also discussed synchronization of stores/, although that issue concerned stores not being initially added to Git. In this case, the stores already existed in Git and were later explicitly deleted.

Requested migration integrity checks

Vault migrations should perform stronger integrity checks before the migrated vault is accepted and Git synchronization is allowed to continue.

For example, before migration XPipe could capture:

old vault version: X
categories: N
stores: M
git-synchronized stores: S

After migration:

new vault version: Y
categories: N'
stores: M'
git-synchronized stores: S'

XPipe should verify that the migration did not unexpectedly lose entries.

At minimum, I would suggest validating:

• Number of stores before and after migration
• Number of categories before and after migration
• UUID set of all stores before and after migration
• UUID set of Git-synchronized stores before and after migration
• Parent/category relationships
• Whether every migrated store can be loaded/deserialized
• Whether encrypted stores can be decrypted with the migrated vault/user configuration
• Whether every Git-synchronized entry that existed before migration still exists afterward

If entries unexpectedly disappear during migration, XPipe should abort the migration or disable Git synchronization, rather than accepting the new state and potentially committing deletions.

For example:

Migration validation failed

Previous synchronized stores: 21
Migrated synchronized stores: 0

21 synchronized entries would be removed.

Git synchronization has been disabled.

The user could then inspect or recover the vault without destructive changes being propagated to the remote repository.

Failed loading/decryption must not become deletion

A particularly important invariant should be:

Failure to load, decrypt, deserialize, or migrate an existing store must never be interpreted as the user intentionally deleting that store.

If a store cannot be loaded during migration, it should be preserved and reported as an error rather than removed from Git.

Bulk deletion protection

There should ideally also be protection against unexpectedly large Git deletions.

For example, if XPipe is about to remove:

21 / 21 synchronized stores

or a significant percentage of the vault immediately after:

• a migration,
• an upgrade,
• first startup,
• unlocking an encrypted vault,
• or synchronization from another machine,

XPipe should not automatically commit and push those deletions.

It could instead:

• abort the sync;
• show a warning;
• require explicit confirmation;
• disable Git synchronization temporarily;
• or create an automatic recovery point before proceeding.

A vault migration or temporary inability to load/decrypt entries should never propagate into a destructive remote Git update.

Automatically tag every vault version commit

I would also suggest automatically creating and pushing a Git tag whenever XPipe creates an:

Update vaultversion

commit.

The tag should exactly match the value written to the vaultversion file.

For example:

vaultversion:
24.1.1

and:

<commit> Update vaultversion

should automatically produce:

24.1.1 -> <commit>

and push that tag to the configured remote.

This would provide a deterministic recovery point for every vault format migration.

The Git history would then naturally look like:

23.9
 |
 | migration
 v
23.99
 |
 | migration
 v
24.0.x
 |
 | migration
 v
24.1.1
 |
 | normal category / connection / preferences updates
 v
HEAD

This makes recovery much easier because users would not have to manually inspect Git history to determine which commit corresponds to a known-good vault format.

It would also make debugging migration problems much easier:

git diff 23.9 24.0.x
git diff 24.0.x 24.1.1

can immediately show exactly what each vault migration changed.

Tag only after migration validation succeeds

Ideally the order would be:

1. Prepare migration
2. Migrate vault
3. Validate categories/stores
4. Validate encrypted entries
5. Validate synchronized entries
6. Commit "Update vaultversion"
7. Create tag matching vaultversion
8. Push commit + tag
9. Re-enable normal Git synchronization

That way a vault version tag effectively means:

This vault successfully completed migration to this format and passed integrity validation.

This would provide a much safer upgrade path, especially for users synchronizing the same encrypted vault across multiple operating systems.