All connections dropped with "protocol error on index-update" and "file with empty block list" after upgrading to v2.0.0-rc.21

Yesterday, I upgraded most devices to v2.0.0-rc.21, and today I’m experiencing huge problems with the following error messages:

2025-06-18 23:06:08 Lost primary connection to UDPWEVD at 192.168.50.253:62206-141.95.19.155:22067/relay-client/TLS1.3-TLS_AES_128_GCM_SHA256/WAN-P50-62A7SAMII3Q48232E86IP1DMSA: protocol error on index-update for 7vafc-tydfh: "xxx": file with empty block list (0 remain)
2025-06-18 23:06:08 Connection to UDPWEVD at 192.168.50.253:62206-141.95.19.155:22067/relay-client/TLS1.3-TLS_AES_128_GCM_SHA256/WAN-P50-62A7SAMII3Q48232E86IP1DMSA closed: protocol error on index-update for 7vafc-tydfh: "xxx": file with empty block list

The result is basically all connections being dropped immediately with no further synchronisation happening :frowning:.

Have you got any ideas what the culprit may be? I will probably try to downgrade to v2.0.0-rc.20 and see what happens then.

I only know that I have it too, and it’s not reproable on new ignored stuff. I suspected it might be something relating to these files and my setup/db being ancient, and hoped no-one else would be affected. I guess given it’s you, it might still be related to ancient files :slight_smile:
Anyway I clearly need to dig into it, but it’s not going to happen this week.

Thanks for a quick reply! I’ve tried downgrading, but it didn’t help, so I tracked down the few files that were listed in the logs instead. The problematic files aren’t very old though, and the problem seems to have began after they’d been modified yesterday evening.

Just for the record, all affected devices are on v2 already, with no v1 in the mix.

1 Like

Yeah, I think I see the problem, cooking a fix. It will require a database fixup as well…

I’m not really sure how to trigger it though, it needs to be a remote invalid file that comes in, gets stored, reprocessed somehow and resent. We don’t resend invalid files very often? Something something ignore patterns receive-only :man_shrugging:

2 Likes

Do you think I should try cherry-picking the current PR, or should I wait for the final version (with the database fixup)?

The situation, unfortunately, has become worse, as more and more files are recorded with the same error, and now even the Web GUI itself is inaccessible, unless I pause all folders. Otherwise, it just gets stuck with a “connection error” blocking all other actions.

You’re the one seeing the error and we need someone to verify if that is the fix, before there is a final version.

No problem :slight_smile:. Do I understand correctly that I should also reset the database to actually see the effect?

Hi:

I think I’m seeing the same issue here on RC21 (the only v2 machine in this cluster).

I had been troubleshooting it on the basis of having had a corrupt DB pre-v2 upgrade, having to reset it, finding some curious behaviour post-reset, upgrading to v2, still finding some curious behaviour, removing select folders to troubleshoot, wondering if its just CPU constrained, etc…

I’m also seeing many more Disconnected Remote Devices than I would expect - but they tend to flit between Disconnected (mostly) and Up To Date/Syncing.

Yes - I’ve got a bunch of those in my logs too…

However, as far as I can see, the noted files would never have come close to an Ignore Pattern or a Receive-Only device.

Sorry - not much to go on, I know… Please let me know if I can provide any further info.

Correction - it looks like the files are ignored by at least one machine in the network, and a cursory look suggests the ‘file with empty block list’ messages are coming from one such machine; other Remote Devices in the network will have the file but will definitely not be ignoring it.

EDIT: the messages are coming from machines both with and without the Ignore Pattern.

The Ignore Pattern would have been in place well before the affected file was created.

No, the migration in the pull request handles this.

I was unfortunately too impatient and already reset the database on some of the devices :sweat_smile:. They are rescanning and rehashing everything now, so once this is done, I’m going to reconnect and see if the issue comes back or not.

It’s good to know that the problem should be fixed during the migration though, as I’ve got some other devices with no direct access, which I cannot easily reset.

Edit:

After ~20 hours or so, I think I can confirm that with the fix applied, the issue seems completely gone :slight_smile:.

I see RC22 is now up - many thanks as always. :grinning_face:

How would you best recommend resolving an RC21 instance with this issue? Re-migrate from the LevelDB files? If so, I might be minded to just remove and re-add affected folders from the existing installation, unless you’d advise against that approach.

Just install rc-22 and it should resolve.

2 Likes

Woohoo! Looks like it’s working - thankyousomuch!! :grinning_face:

3 Likes

Should I also release the RC 22 Android build? Or is this just affecting the minority of users?

1 Like

A bit late: Yes, would very much recommend it. The impact is bad and if three people report it on the forum based on an RC, that is a pretty good indicator that it is not too niche. At the same time many aren’t effected and the three reporters aren’t exactly “light users”, so I am not saying it’s definitely not niche xD
Anyway, if you can release with reasonably low effort, it’s always good to do it, and imo even a bit more good (sic!) here :slight_smile:

2 Likes

Yes, no problem since this Docker thingy is running.

1 Like