Database corruption renders extension unusable with no obvious way to fix it

Describe the bug

My clipboard history has suddenly stopped working, always displaying a blank list. After many days of thinking my distro was to blame, I was finally motivated enough to debug it. My database.log was somehow corrupted: at some point in time, OP_TYPE_SAVE_TEXT <new entry text>, OP_TYPE_DELETE_TEXT <oldest entry id> started to get written to the file not once, but twice every time I copied something. Since then, whenever the extension was enabled, it crashed on this line after trying to delete an entry which was already deleted.

I was unable to reproduce the bug and I don’t know how to prevent it, but I suggest the following changes:

• Make the extension more resilient to this kind of data corruption (log warnings instead of crashing)
• In case of a critical error, notify the user and offer them to report a bug and reset the DB

How To Reproduce

Versions

GNOME Shell 42.4
GCH   Version: 15
org.gnome.shell.extensions.clipboard-history cache-only-favorites false
org.gnome.shell.extensions.clipboard-history cache-size 100
org.gnome.shell.extensions.clipboard-history clear-history @as []
org.gnome.shell.extensions.clipboard-history confirm-clear true
org.gnome.shell.extensions.clipboard-history disable-down-arrow false
org.gnome.shell.extensions.clipboard-history display-mode 2
org.gnome.shell.extensions.clipboard-history enable-keybindings true
org.gnome.shell.extensions.clipboard-history history-size 10
org.gnome.shell.extensions.clipboard-history move-item-first true
org.gnome.shell.extensions.clipboard-history next-entry @as []
org.gnome.shell.extensions.clipboard-history notify-on-copy false
org.gnome.shell.extensions.clipboard-history paste-on-selection true
org.gnome.shell.extensions.clipboard-history prev-entry @as []
org.gnome.shell.extensions.clipboard-history private-mode false
org.gnome.shell.extensions.clipboard-history process-primary-selection false
org.gnome.shell.extensions.clipboard-history strip-text false
org.gnome.shell.extensions.clipboard-history toggle-menu ['<Super>V']
org.gnome.shell.extensions.clipboard-history toggle-private-mode ['<Super><Shift>P']
org.gnome.shell.extensions.clipboard-history topbar-preview-size 10
org.gnome.shell.extensions.clipboard-history window-width-percentage 26

Steps to repro

I couldn’t find out what caused the corruption, but I could replicate it by modifying the code in a such way that enable() always gets called twice.

Additional context (if a crash, provide stack trace)

Aug 20 18:21:24 leginix .gnome-shell-wr[2247]: JS ERROR: TypeError: undefined has no properties
                                               loop/<@/home/v/.nix-profile/share/gnome-shell/extensions/[e-mail]/store.js:144:56
                                               parseAvailableAware@/home/v/.nix-profile/share/gnome-shell/extensions/[e-mail]/store.js:189:7
                                               loop@/home/v/.nix-profile/share/gnome-shell/extensions/[e-mail]/store.js:142:26
                                               loop/<@/home/v/.nix-profile/share/gnome-shell/extensions/[e-mail]/store.js:137:11

[SUPERCILEX]

I disagree: I think it’d be worth it even if there were no bugs that could cause a corruption (and they wouldn’t appear in the future), because software shouldn’t fail silently, especially due to a malformed file in ~/.cache. Plus that might have caused and may cause less determined users to give up before they fix it and/or file an issue.

That’s a great point. I won’t have time to work on this soon, but I created #97 to track this.

I’m not sure if that’s what happened though, and if it is, it could instead be something for GNOME to address.

Yeah, I’m adding an initialization check that I hope will help, but it’s perfectly possible that there are multiple gnome shell instances running. That one would be much more difficult to work around, though should be possible with a lock file.

[SUPERCILEX]

Dang, well let me know if it happens again. 👍 And please just cp ~/.cache/[e-mail]/database.log somewhere if so. 😃 Even if you don’t want to give it to me, at least we can do a bit of analysis on it.