Migration to EteSync 2.0: Error "Thread.currentThread().contextClassLoader must be set"

[eomanis]

The migration was successful, this is only about some glitch in the migration process, I just wanted to report it.

Migration from self-hosted EteSync 1.0 server to self-hosted EteSync 2.0 server

Server

• Arch Linux
• EteSync 1.0 instance: AUR package etesync-server-0.3.0-1
• EteSync 2.0 instance: AUR package etebase-server-0.7.0-1
• Both instances on same system behind single nginx instance (also on this system) using different ports / virtual hosts
• Both instances on bare metal / no Python virtual environment
• Both instances running with uWSGI (uwsgi-plugin-python 2.0.19.1-10), nginx communication through Unix socket

Client

• com.etesync.syncadapter 2.2.4 from F-Droid store
• Google Pixel / sailfish
• LineageOS 17.1 from April 03 2021, build number lineage_sailfish-userdebug 10 QQ3A.200805.001 2b1abb669f

Migration report

Initiated migration of the profile in the EteSync app At selection what to migrate, selected everything (1 address book, 1 calendar, 1 task list) and clicked "CREATE"

Pop-up, title: An error has occurred. Pop-up, text: Thread.currentThread().contextClassLoader must be set Closed pop-up with single option "OK"

Clicked "CREATE" again Migration commences and finishes without issues, however on the target account there are two task lists with the same name; the first one of them is empty (maybe from first failed migration attempt?) Deleted the empty task list and now everything is well

[eomanis]

I would at this point like to thank you guys for the truly superb server installation and migration guide, along with the fact that the old and new AUR packages do not conflict with each other, making running them both at the same time during the migration a piece of cake.

Also thank you for providing these AUR packages in the first place, and keeping them working without requiring a virtual environment. This smells like some very well-maintained code.

[tasn]

Thanks for reporting, and thanks for your kind words. :)

[eomanis]

For what it's worth, I noticed that logging into the administrative web interface of the EteSync 2.0 server logged me out of / invalidated my session at the EteSync 1.0 server, and vice-versa.

They are both using the same domain name, and presumably they overwrite each other's cookies in the web browser. Might be that something like this caused the glitch when the migration was juggling both servers simultaneously.

If that is the case, it definitely is not a bug, it is just how web sessions work. So, if you want a flawless migration experience, don't host both servers on the same domain name. Or, y'know, just get a regular account subscription on the official servers 😉.

[tasn]

Ah yeah, the same domain thing is annoying. :)