XBEL items with no @id attribute get NaN ids, causing duplicated folders and false-positive deletion failsafe

[Matovidlo]

Version of floccus

5.10.2

How many bookmarks do you have (approximately)?

Reproduced with as few as 4 (isolated test), but the same mechanism was observed in production with several hundred, where it tripped the failsafe at 100%.

Do you use any other means of syncing your bookmarks momentarily?

No

How do you sync your bookmarks?

WebDAV

Browser and version

Firefox (current stable), Floccus WebDAV account

Which WebDAV server do you use?

Reproduced with marlluslustosa/floccuswebdav (nginx WsgiDAV) test container, and independently observed against a self-hosted lo-floccus/WebDAV setup in production. Not specific to one WebDAV server — the bug is in Floccus's own XBEL parsing, not the transport.

Describe the Bug

XbelSerializer._parseFolder (src/lib/serializers/Xbel.ts) parses an item's id with plain parseInt(node[':@']['@_id']). If the <folder>/<bookmark> element has no @id attribute at all (or a non-numeric one), parseInt(undefined) returns NaN, and that NaN is later serialized back to the file as the literal string id="NaN" (String(NaN)).

Because NaN !== NaN in JavaScript, any subsequent sync that tries to match this item against the cache/local tree by id can never recognize it as "the same item" — every comparison involving that id fails. In our reproduction this caused Floccus to treat the same folder as brand-new on each sync and duplicate it (we saw one folder triplicated across 3 sync cycles). Once the local/cache/server trees disagree about that much of the tree, the diff looks like a mass deletion, and the "would delete N% of your local links" failsafe (E050) fires — we reproduced it at 40% in the small isolated case; in the wild, on a bigger tree with more affected folders, it can reach much higher percentages (we saw 100% in production).

Folders/bookmarks end up with no @id in the first place whenever something writes the XBEL file without one (e.g. any external tool that manipulates the file directly and omits empty/zero id attributes on serialization, or a first-ever sync of a local-only folder before Floccus has assigned it an id) — Floccus should tolerate that gracefully instead of poisoning its own id space with NaN.

Expected Behavior

An item with a missing/invalid @id attribute should be assigned a fresh, valid, and stable id on parse (so it round-trips identically on the next sync), instead of NaN. It should never be possible for the failsafe to be triggered purely because of an id-parsing artifact rather than an actual bookmark change.

To Reproduce

1. Point Floccus at a WebDAV account whose bookmarks.xbel contains a <folder> (or <bookmark>) with no @id attribute, e.g.:

   <folder>
     <title>NewProjectFolder</title>
     <bookmark href="https://en.wikipedia.org/wiki/First"><title>First dream</title></bookmark>
   </folder>

2. Sync — Floccus pulls this down into the local browser tree.
3. Add any bookmark locally inside that folder (or otherwise cause a local change under it) and sync again, so Floccus needs to write the tree back to the server.
4. Inspect the resulting bookmarks.xbel on the server: the folder now has id="NaN", and after another sync cycle with a further local change, the same folder gets duplicated instead of updated.
5. With a large enough affected subtree, this trips: Failsafe: The current sync run would delete N% of your local links in this profile. Refusing to execute.

I have a debug log from the reproduction and a minimal fix ready — see PR #.

• I will attach a debug log of the sync run that produced the error (available on request; reproduced in an isolated test environment, not my personal data)

---

If you like floccus, please consider supporting it financially so it can be maintained long-term. Thank you!

[github-actions]

Hello! 👋

Thank you for taking the time to open this issue with floccus. I know it's frustrating when software causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at and if possible solved. Let me give you a short introduction on what to expect from this issue tracker to avoid misunderstandings. I'm Marcel. I created floccus a few years ago, and have been maintaining it since. I currently work for Nextcloud which leaves me with less time for side projects like this one than I used to have. I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it. Until then, please be patient. It helps when you stick around to answer follow up questions I may have, as very few bugs can be fixed directly from the first bug report, without any interaction. If information is missing in your bug report and the issue cannot be solved without it, I will have to close the issue after a while. Note also that GitHub in general is a place where people meet to make software better together. Nobody here is under any obligation to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can collaborate to make this software better. For everyone. Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and try to fix the odd bug yourself. Everyone will be thankful for extra helping hands! If you cannot lend a helping hand, to continue the development and maintenance of this project in a sustainable way, I ask that you donate to the project when opening an issue (or at least once your issue is solved), if you're not a donor already. You can find donation options at https://floccus.org/donate/. Thank you!

One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the Nextcloud forum, to twitter or somewhere else. But this is a technical issue tracker, so please make sure to focus on the tech and keep your opinions to yourself.

Thank you for reading through this primer. I look forward to working with you on this issue! Cheers! 💙