Account-encrypted web backup fails to restore locally with "invalid block type"; partial backup restores successfully #1641

Summary

An account-encrypted full local backup exported from the RisuAI website fails to restore in the Windows desktop app with Error: invalid block type. A partial local backup exported from the website successfully restores in the same desktop installation.

The encrypted-backup restore path appears to continue decoding the encrypted database after key retrieval or decryption fails, obscuring the underlying error.

Environment

• RisuAI version: 2026.8.250
• OS: Windows 10.0.19045
• Risu environment: local / Tauri
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36 Edg/154.0.0.0
• Backup source: RisuAI website, using account sync on mobile.

Steps to reproduce

1. In the account-synced web version, export a full backup using Save Backup Locally.
2. In the Windows desktop version, select Load Backup Locally and choose that .bin file.
3. The import fails with Error: invalid block type.
4. As a comparison, import a backup created with Save Partial Backup Locally (Excluding Character Assets). This backup loads successfully in the same desktop app.

The partial-backup restore was tested successfully by the reporter. The full export is not attached because it contains private data.

Actual error

Stack trace translation failed. Showing original obfuscated stack trace below.

Error: invalid block type
    at O (http://tauri.localhost/assets/browser-NW1CkfGq.js:1:3288)
    at De (http://tauri.localhost/assets/browser-NW1CkfGq.js:1:14293)
    at Ue (http://tauri.localhost/assets/browser-NW1CkfGq.js:1:17751)
    at TE (http://tauri.localhost/assets/database.svelte-6wcmeoV8.js:1627:29570)
    at e.onchange (http://tauri.localhost/assets/index-5ATvJaXI.js:151:1919)

Read-only diagnostic findings

• The failed full-backup container parses completely, with no truncated entries. It contains encryption.risudat with type: "account" and a database.risudat entry. A complete container does not establish the integrity of the encrypted payload.
• Independent requests to the official https://sv.risuai.xyz/cryptokey?key=<backup timestamp> endpoint returned HTTP 403 Forbidden. Tests included requests with desktop/web Origin headers and navigation in an isolated headless Microsoft Edge context.
• These were separate diagnostic requests, not a capture of the request inside the failing desktop app. They support a key-service access hypothesis but do not conclusively establish the app's exact decryption failure.
• Passing the still-encrypted database.risudat payload directly to fflate@0.8.2's decompressSync reproduces the exact invalid block type error.
• The successful partial backup has no encryption metadata. Its compressed Risu header, fflate decompression, independent gzip integrity check, and MessagePack decoding all passed before the reporter tested the actual desktop restore.

Source-code finding

In LoadLocalBackup at v2026.8.250, a key-fetch/decryption error is caught and reported, but execution continues to decodeRisuSave(db) with the original encrypted database bytes.

decodeRisuSave has a fallback that attempts fflate.decompressSync on the input. For this encrypted payload, that produces the misleading decompression error above.

The full and partial exporters also differ in whether they apply account encryption:

• Full backup encryption branch
• Partial backup database export, without that branch

Suggested improvement

Would it be possible to check the key-service access used when restoring account-encrypted backups in the desktop app?

If the key cannot be retrieved or decryption fails, it would also be helpful to stop the import at that point and display the underlying error. Checking the HTTP status and key response before decryption may make the problem easier to understand, rather than falling through to invalid block type.

The partial export is a working workaround for me, but it excludes additional media, so I would still appreciate being able to restore the full backup.

Thank you for maintaining RisuAI and taking a look. I hope the comparison and diagnostic notes above help narrow this down.