Introduction
Rocket.Chat Desktop recently released version 3.0.2. In this release Rocket.Chat team introduced Server validation and hard-coded the minimum required Rocket.Chat server version of 2.0.0.
With this breaking change, Rocket.Chat Desktop will no longer work on Rocket.Chat Server running on version < 2.0.0. If you try connecting to Rocket.Chat server running an older version, you’ll be prompted with the following message.
Firstly, the message is vague and unclear, and at first, the user will try to double-check if they have entered the correct URL. Secondly, this message has nothing to do with the server version. A more appropriate message would have been:
“You are connecting to the server that is running an older version and is no longer supported. Please upgrade your Rocket.Chat server.”
Many users and companies who are running Rocket.Chat server version < 2.0.0 in production is suddenly left with one option, UPGRADE!
However, an overnight server upgrade is not possible for any production software unless it’s Heartbleed of course.
One of the possible workarounds is to request end-users to re-install the older version of Rocket.Chat Desktop < 3.0.0, which doesn’t perform the Server Validation. But in reality, this is not feasible when you have 100s of users!
Let’s buy us some time!
Alright, we know the upgrade is mandatory but not possible overnight. So now what!
I began drilling into the Rocket.Chat Desktop source code to figure out how Server validation is actually performed under the hood.
In line no. 18, the server version information is fetched by requesting api/info endpoint. If you curl this endpoint, it’ll return the server version information as JSON response:
Hmm…that’s interesting. The version information is then parsed from JSON response and is compared against the hard-coded REQUIRED_SERVER_VERSION_RANGE.
Well, what if we modify the JSON response on the fly and return a version ≥ 2.0.0 without upgrading the server. If you have deployed Rocket.Chat server behind AWS load-balancer then we can add a custom rule and craft a custom JSON response using Fixed Response feature of AWS ALB.
And voila! we’ve upgraded the server in the eyes of Rocket.Chat Desktop.
With this simple change, if you now try connecting to the server using the latest Rocket.Chat Desktop version. Not surprisingly, it will connect even though the server is still running an older version.
Your users should now be able to connect to the server and use the latest Rocket.Chat Desktop normally.
WARNING! Do not use this “hack” as a permanent fix. This “hack” allows your team some breathing space while you start planning on upgrading the Rocket.Chat server version.
Conclusion
Rocket.Chat Team should have kept the backward compatibility with the older server version and gave a deadline to act. Instead, they went the other route and forced everyone to upgrade immediately. Anyway, if you are still running an older server version then it’s about time you plan your upgrade soon!
P.S. Rocket.Chat is a really good open-source communication and collaboration tool. If you haven't check it out. https://rocket.chat/
Top comments (1)
As one of the maintainers, I'd like to apologize for the inconvenience. When introducing the breaking changes of version 3.x, we've noticed that some features were already incompatible with the app, like the handling of the user presence and some touch bar buttons for MacOS users. At the time, I've considered fair enough to raise our minimum supported version to
>=3.0.0, but our team warned me that our support covers the latest major versions -- therefore,>=2.0.0. The front-end team has the long-term goal to not render the server's web client inside the app, but provide a completely local client (even if running over Electron or, maybe, React Native Desktop). It was surprising to discover how many community instances of versions 0.x and 1.x are running out there; so we're committed to support all previous versions with some form of "graceful degradation" in the next patches.