favoriteGifs stops saving once the field passes its 64KB budget, UI still says it saved

Observed behaviour

After you have enough favorite GIFs, adding or removing one stops working. The UI updates and you get the usual "Added to favorite GIFs" / "Removed from favorite GIFs" toast, so it looks like it worked, but after a reload the change is gone and removed GIFs come back. The console shows: [SyncedField] [Error] .favoriteGifs: payload of 69666 bytes exceeds per-field budget of 65536; push dropped. No PATCH to /users/@me/settings is sent, so nothing reaches the server. The limit is in fluxer_app/src/features/user/state/SyncedField.ts (maxEncodedBytes ?? 65_536) and it's checked before the request is built. Each favorite stores the page URL, the proxy URL and the base64 source URL, which works out around 3KB per GIF. It took 20 KLIPY GIFs to go over on Canary, tested twice with completely different sets and got the same count both times, though the exact number will depend on how long the URLs are. On my self-hosted instance it was 43, but over half of those were older ones that are smaller. What makes it hard to notice is the toast says it saved, there's no warning as you approach the limit, and once you're over it you can't delete favorites either, so anything broken in the list is stuck there until you remove enough others to get back under. Reproduced on web.canary.fluxer.app as well as my self-hosted instance, so it isn't a self-hosting thing.

Reproduction steps

Open devtools console
Favorite GIFs from the KLIPY picker until the "push dropped" error shows in the console (about 20 for me, but it depends on URL lengths so add a good few past that to be safely over)
Keep going a bit past that point (every add still shows the "Added to favorite GIFs" toast like it worked, but the console keeps printing the error and no PATCH to /users/@me/settings is sent)
Try removing any GIFs from the favorites you just added (toast says removed, console says dropped)
Refresh the page. Everything you did past the limit is gone, you're back to the last state that actually saved
Now you're under the cap again, so saving works until you go over once more

Build information

Canary Web 2026.822.81738, Linux (x86), Chrome 151.0.0.0, Locale en-US; Also on self-hosted: Stable Web 2026.816.210712, Linux (x86), Chrome 151.0.0.0, Locale en-US

Platform

Web, Self-hosting

Evidence

Console error:

[SyncedField] [Error] .favoriteGifs: payload of 69666 bytes exceeds per-field budget of 65536; push dropped.

On my self-hosted instance: changing the theme writes the user_settings row immediately, but favoriting a GIF never touches it. UserSettings:syncedPreferencesLocal and ...Wire stay byte-identical in localStorage. Adding a gif after the cap: image Removing a gif while still over the cap: image

1 comment

HampusStaff 1 vote 25d ago originally by @hampus-fluxer on GitHub

This is now fixed. You can now store between approximately 1,400–2,000 favourite GIFs. I'm working on changing the architecture of this system to make it store a more unbounded, less variable amount.