legendkeeper
patreon
LegendKeeper 0.9.0.5
🕑 Added 2021-05-30 05:25:16 +0000 UTC* LK Client now sends version number along with connection handshake.
TL;DR: Tiny change in preparation for a larger one tomorrow, but requires some context. Starting tomorrow, I will be forbidding connections from clients that do not send their version number (i.e., any LK clients that aren't 0.9.0.5). So you might get the "Offline" cloud icon until you get the update prompt or close all instances of LK and shift+refresh your browser. Justification below.
On May 15th I deployed the first release candidate for Hydra, which I had to roll back about 12 hours later. That Hydra client had an issue that caused opening a wiki page to sometimes erase all its metadata, and prevent further edits to it. This is obviously bad. I fixed this issue, and when I deployed Hydra the second time on May 25th, I was on high-alert for spotting this bug again, just in case.
I didn't see it all week, until today I woke up and 2 projects started experiencing metadata corruption. By the end of the day, 7 projects had experienced the corruption. For stats disclosure, that's 7 out of the 2000 currently migrated projects, with about 420 pages out of the 400,000 currently migrated pages. Most of the corrupted metadatas are in one project. This puts the corruption rate at about 0.001%. Still, anything above zero is unacceptable to me.
Given that all affected parties I've talked to participated in the first botched Hydra launch, and the fact that corruption is confined to a small number of projects, rather than spread around evenly, and it didnt' start happening until today, the working theory is this: Today is Saturday and folks are playing D&D, so players were logging in to LegendKeeper after a week or two of hiatus. Your LegendKeeper client is cached on the device, so these players logged in with the old client that then started corrupting the wiki pages they were opening.
The database doesn't like corrupted metadata, so will reject updates that are corrupting, but the cache doesn't care, as it's optimized for speed, not analysis and validation. So the corrupted documents are currently sitting in the cache, preventing updates and overall causing a nuisance for the 7 folks affected by this. There's old, but uncorrupted metadata sitting in the central DB. Once the sync server is updated to reject connections from old clients, I will clear the 420 corrupted metadatas from the cache, which will hopefully allow the affected parties to resume. Rolling back these metadatas to their database versions may mean that any changes to names, tags, permissions, hidden state in the last 24 hours or so, etc. may be lost for the 7 affected projects. As far as I'm aware, pins and actual text within wiki pages are unaffected, as they use a different mechanism not subject to the same corruption bug.
I understand this is an inconvenience to the 7 affected parties, and will be sending them a personal apology as well as instructions on how to proceed.
Anyways, just wanted to keep everyone updated on what's going on. Today was a rough day; I'm glad only a small number of people were affected, but still I'd like LK to be perfect when it comes to protecting your data.
Braden
