Restoring settings from backup breaks further server-side updates #405

New issue

Closed

opened 2024-06-28 16:54:21 +00:00 by Oneric · 0 comments

Oneric commented

2024-06-28 16:54:21 +00:00

Member

Version

8765491

What’s wrong?

Steps to reproduce:

Have used akkoma-fe for a while so that the current profile version is > 3
Take a backup of the current profile via the settings UI
Delete the profile and recreate it
(alternatively the same may happen when migrating instances/accounts)
Restore the backed up settings
Observe no further changes being saved on the server

The backup contains a "profileVersion" property recording the version number at time of backup. When restoring the backup, this property gets added into the "settings" object.
akkoma-fe will show the value of the outer "version" property in the profile overview, but the value of the "profileVersion" property inside "settings" when showing what’s currently used.

The server only parses the outer "version" property and expects it to increase by exactly one each update. However, akkoma-fe will use the value from "profileVersion" when sending PUT update requests to the server, leading to the request being rejected. Thus no new changes get stored on the server.

What should happen instead?

akkoma-fe should either fully restore the old profileVersion value, or disregard it entirely. I believe each can be achieved like follows:

Restore old version value:

when restoring from a backup, first DELETE the current profile
extract profileVersion from the backup and recreate the profile with this version and do not include "profileVersion" within settings

Disregard old version value:

delete profileVersion from the backup before restore

Additionally, given some already restored backups, the current logic for determining the version to use should also be adjusted to disregard the profileVersion field within settings.

On a side note: i noticed restoring from backup can take quite a while; my tab was frozen for several seconds. I don't know what akkoma-fe is doing here. Switching profiles or logging in (initially loading the profile) doesn't come with such a large perf overhead.
Going with the DELETE + restore with old version, then refresh. approach might speed things up.

Workaround

If you’re affected by this and read this before it is fixed; here’s a manual workaround. This assumes your profile is called default and your instance is otp.akkoma.dev, replace as necessary.

While logged in on your instance open your browser’s network request tab.
Find an API request (search e.g. for /api/v1/timelines, click on it and copy the value of the Authorization request header

In your terminal do

curl -H 'Authorization: Bearer <copy from browser headers>' -D - -o tmp.json -X GET https://otp.akkoma.dev/api/v1/akkoma/frontend_settings/pleroma-fe/default

Edit tmp.json to:
- increase the top-level "version" field by one
- delete the profileVersion property inside the settings object

Again in the terminal do

curl -H 'Authorization: Bearer <same as before>' -X PUT -H 'Content-Type: application/json' -i --data "$(cat tmp.json)" https://otp.akkoma.dev/api/v1/akkoma/frontend_settings/pleroma-fe/default

Severity

I can manage

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Version 8765491 ### What’s wrong? Steps to reproduce: 1. Have used akkoma-fe for a while so that the current profile version is > 3 2. Take a backup of the current profile via the settings UI 3. Delete the profile and recreate it (alternatively the same may happen when migrating instances/accounts) 4. Restore the backed up settings 5. Observe no further changes being saved on the server The backup contains a `"profileVersion"` property recording the version number at time of backup. When restoring the backup, this property gets added into the "settings" object. akkoma-fe will show the value of the outer `"version"` property in the profile overview, but the value of the `"profileVersion"` property inside `"settings"` when showing what’s currently used. The server only parses the outer `"version"` property and expects it to increase by exactly one each update. However, akkoma-fe will use the value from `"profileVersion"` when sending PUT update requests to the server, leading to the request being rejected. Thus no new changes get stored on the server. ### What should happen instead? akkoma-fe should either fully restore the old `profileVersion` value, or disregard it entirely. I believe each can be achieved like follows: **Restore old version value**: - when restoring from a backup, first `DELETE` the current profile - extract `profileVersion` from the backup and recreate the profile with this version and do *not* include `"profileVersion"` within settings **Disregard old version value**: - delete `profileVersion` from the backup before restore Additionally, given some already restored backups, the current logic for determining the version to use should also be adjusted to disregard the `profileVersion` field within settings. On a side note: i noticed restoring from backup can take quite a while; my tab was frozen for several seconds. I don't know what akkoma-fe is doing here. Switching profiles or logging in (initially loading the profile) doesn't come with such a large perf overhead. Going with the DELETE + restore with old version, then refresh. approach might speed things up. ### Workaround If you’re affected by this and read this before it is fixed; here’s a manual workaround. This assumes your profile is called `default` and your instance is `otp.akkoma.dev`, replace as necessary. 1. While logged in on your instance open your browser’s network request tab. 2. Find an API request (search e.g. for `/api/v1/timelines`, click on it and copy the value of the `Authorization` request header 3. In your terminal do ```sh curl -H 'Authorization: Bearer <copy from browser headers>' -D - -o tmp.json -X GET https://otp.akkoma.dev/api/v1/akkoma/frontend_settings/pleroma-fe/default ``` 4. Edit tmp.json to: - increase the top-level "version" field by one - delete the `profileVersion` property inside the `settings` object 5. Again in the terminal do ```sh curl -H 'Authorization: Bearer <same as before>' -X PUT -H 'Content-Type: application/json' -i --data "$(cat tmp.json)" https://otp.akkoma.dev/api/v1/akkoma/frontend_settings/pleroma-fe/default ``` ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.