Bug 39314 - RabbitMQ can't upgrade from 3.x to 4.x without running a data migration on 3.13
Summary: RabbitMQ can't upgrade from 3.x to 4.x without running a data migration on 3.13
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Installation and upgrade (command-line installer) (show other bugs)
Version: Main
Hardware: All All
: P5 - low major
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-12 08:45 UTC by Victor Grousset/tuxayo
Modified: 2025-03-16 23:47 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Grousset/tuxayo 2025-03-12 08:45:05 UTC
Reported to Debian as it affects their next release which will do a jump from 3.10 to 4.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100165#10

Which can't work: https://www.rabbitmq.com/docs/upgrade
«You can only upgrade to RabbitMQ 4.0 from RabbitMQ 3.13.» 

«stable feature flags have to be enabled before the upgrade. The upgrade 
will fail if you miss this step.»

See there more more details.

-----

For us: is there still data in RabbitMQ when stopping a Koha instance and upgrading it? I recall reading that the DB was basically mirroring the message queue data during a discussion about the actual need for a dedicated message queue. Does it mean the koha-common package can wipe the RabbitMQ data which will allow it to start without issue?
Comment 1 David Cook 2025-03-14 01:57:36 UTC
(In reply to Victor Grousset/tuxayo from comment #0)
> Reported to Debian as it affects their next release which will do a jump
> from 3.10 to 4.0:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100165#10
> 
> Which can't work: https://www.rabbitmq.com/docs/upgrade
> «You can only upgrade to RabbitMQ 4.0 from RabbitMQ 3.13.» 

That's fun...

> For us: is there still data in RabbitMQ when stopping a Koha instance and
> upgrading it? I recall reading that the DB was basically mirroring the
> message queue data during a discussion about the actual need for a dedicated
> message queue. Does it mean the koha-common package can wipe the RabbitMQ
> data which will allow it to start without issue?

The DB stores the jobs, and the Koha app passes messages to background workers via RabbitMQ.

If the background worker starts up and can't get a connection to RabbitMQ, it'll query the DB directly for the jobs. 

What this means is that if you stopped koha-common, nuked RabbitMQ, re-installed RabbitMQ, and started koha-common, you could have data loss if there were any messages in RabbitMQ that hadn't been processed.
Comment 2 David Cook 2025-03-14 02:00:52 UTC
A dedicated sysadmin who knows to look out for the RabbitMQ issue could perform a RabbitMQ reinstall without a problem.

But for someone without sysadmin support... there could be problems depending when the upgrade is performed.

=-

I'm trying to think of workarounds that tried to determine if there was any pending messages and re-queue or otherwise deal with those messages... but it would probably be messy.
Comment 3 Victor Grousset/tuxayo 2025-03-14 07:59:58 UTC
> A dedicated sysadmin who knows to look out for the RabbitMQ issue could perform a RabbitMQ reinstall without a problem

They would have to find a package somewhere for the latest 3.X just for the upgrade. Still quite the hassle >_<
Comment 4 David Cook 2025-03-16 23:47:48 UTC
(In reply to Victor Grousset/tuxayo from comment #3)
> > A dedicated sysadmin who knows to look out for the RabbitMQ issue could perform a RabbitMQ reinstall without a problem
> 
> They would have to find a package somewhere for the latest 3.X just for the
> upgrade. Still quite the hassle >_<

Sure, but it's not uncommon. I think Keycloak requires stepped upgrades for certain versions. PostgreSQL too for really old versions. 

We try to make things seamless for people, but I think there needs to be limits too.