The latest version 6.9.1 not supported

[lovekyleman]

As you can see the photo below

[LiloBzH]

Hello

Same issue here. With the last docker version, i have the same error.

[lovekyleman]

Hello

Same issue here. With the last docker version, i have the same error.

That's not good 😆😆

[chotaire]

Ooookay!

[Gummikavalier]

Same in our test server too with 6.9.1. (Tar install, Enterprise, Offline registered)

No issues with 6.8.1.

[ryanvito]

I've had mixed results. I've been able to restart the container and occasionally it shows up as supported. Not sure if the variability helps.

[casalsgh]

Checking into it folks, will provide updates ASAP

[lovekyleman]

I've had mixed results. I've been able to restart the container and occasionally it shows up as supported. Not sure if the variability helps.

Restart RC can't help here. Still not supported

[thokich]

Hello

Same issue here. With the last docker version, i have the same error.

Restart RC has not help here.

[chotaire]

After reading #31706 and seeing that nobody of the Rocket.Chat team actually ever really resolved this (or gave instructions on how to resolve this), I will cease updating our production Rocket.Chat instance until I see green light here that the issue has been resolved for everyone.

From my understanding this is not just a warning message. This would prevent all mobile and Electron clients from connecting after max. 14 days if I read correctly.

It is absolutely unbelievable how scared one must always be to update this piece of software.

[lovekyleman]

After reading #31706 and seeing that nobody of the Rocket.Chat team actually ever really resolved this (or gave instructions on how to resolve this), I will cease updating our production Rocket.Chat instance until I see green light here that the issue has been resolved for everyone.

From my understanding this is not just a warning message. This would prevent all mobile and Electron clients from connecting after max. 14 days if I read correctly.

It is absolutely unbelievable how scared one must always be to update this piece of software.

Yeah. After that I will carefully update my RC server. RC has a lot of bugs but seems no one really cares about them.

[reetp]

Please note that this is with the dev team for urgent attention.

RC has a lot of bugs but seems no one really cares about them.

I think if you look you will see we have paid a lot more attention to bugs here recently (you are not aware of the internal systems that Rocket uses and the work that goes on behind the scenes).

Gabriel Casals and I have recently been working on getting clear issues resolved/fixed. Some of those will come to pass in due course, but it takes a while to filter through with all the competing priorities that the dev, product and sales teams have. Clearly if you have paid support you can contact support immediately.

Otherwise note that this is open source. The source is there. There is no guarantee about anything else.

However, I am pretty sure there will be a resolution to this fairly quickly.

---

Please note also.

Anyone here using docker with 'latest' should go and change that immediately.

You should NEVER use 'latest' unless you are either developing, or like nasty surprises.

For production fix your versions, watch for issues, upgrade on your own schedule, save yourself grief.

https://docs.rocket.chat/deploy/deploy-rocket.chat/deploy-with-docker-and-docker-compose

Set the RELEASE variable in the .env to your desired Rocket.Chat version.

See our releases page and available docker images. Keeping the default release as latest is not recommended.

Personally I never run with the latest releases - I always stay 0.1 behind so currently on 6.8.x

YMMV.

[chotaire]

@reetp Thank you for the clarification, it's good to hear this is high on the priority list.

[reetp]

NP.

(No need to @ anyone - we do read)

[casalsgh]

Team, fixes are on it's way and so are adjustments to our automated tests. Gathering info on any actions that might be needed from admins. Please bear with me on this one.

[chotaire]

I think if you look you will see we have paid a lot more attention to bugs here recently (you are not aware of the internal systems that Rocket uses and the work that goes on behind the scenes).

Yes, the number of showstopping issues that wreck installations have reduced.

Gabriel Casals and I have recently been working on getting clear issues resolved/fixed. Some of those will come to pass in due course, but it takes a while to filter through with all the competing priorities that the dev, product and sales teams have.

That is great to hear.

Otherwise note that this is open source. The source is there. There is no guarantee about anything else.

Nobody will ever guarantee bugfree software, whether that is opensource or not.

Anyone here using docker with 'latest' should go and change that immediately.
You should NEVER use 'latest' unless you are either developing, or like nasty surprises.

While "not using latest tag in docker" is known practice, the problem lies elsewhere. Please let me elaborate:

a) The latest major version is neither flagged pre-release, nor being on a dev branch, nor otherwise noted unstable. It is assumed latest stable version which is under support.
b) Rocket.Chat major versions have an extremely short lifecycle and new major versions are released very quickly. This only lets admins assume it is about time to update to stay on track with development.

For production fix your versions, watch for issues, upgrade on your own schedule, save yourself grief.

https://docs.rocket.chat/deploy/deploy-rocket.chat/deploy-with-docker-and-docker-compose

Set the RELEASE variable in the .env to your desired Rocket.Chat version.

See our releases page and available docker images. Keeping the default release as latest is not recommended.

Personally I never run with the latest releases - I always stay 0.1 behind so currently on 6.8.x

This is very vital info coming from a dev. This should be extremely visible on the main page of this git. And in many other places. Users should be warned that the latest major version is not assumed stable, that there exists no dev branch and no beta releases. That users are advised to stay one major version behind. This would save countless of admins from extraordinary headache or worse.

Had I not always tested on test instances AND created snapshots of the production instance before upgrading or even just updating to a new minor release, I'd have killed our production instance a remarkable number of times already, or lets say I would have been forced to switch to a different product because users were no longer able to work as expected.

All this because it has never been clear to me that "latest stable" is not stable. May I please suggest that this is made much more visible, or that you would consider to open a dev branch or to the least flag latest major version as pre-release or otherwise make it more obvious?

Please do not forget, there are no downgrade options (HINT!). This gets even more difficult with docker installations. Please help users make the best choice and, if you are not reconsidering your release strategy, at least make an effort by documenting this as visibly as you can.

It is simply the case that most users consider a latest major version being stable. At least stable enough. As an example, Microsoft would not release Windows 11 as an unstable operating system and advise users to stick with Windows 10 until Windows 12 is released. Most other products go the same route. Latest stable is stable. So this creates confusion. I know that some other products of the cloud age follow a similar release strategy: release early, release quickly, but this will require extraordinary QA and automated tests to make sure nothing serious will happen. I would personally recommend a dev branch to prevent the obvious. Damage.

Thanks for your time. And yes, from now on I will stay one major version behind.

[reetp]

This is not really the place for a wider discussion on Rocket - this is a bug tracker - and you should really be discussing this on open.rocker.chat However, some of your comments make assumptions that may mislead others and need correcting.

NB. I am not a dev. I did work for them for a period a few years back and understand the internals but I do not get paid by Rocket now - I am just a trusted community member.

I am a small sysadmin with a bit of experience. I have used Rocket since around 0.16 and learned a few lessons along the way.

I follow my OWN release schedule. It is sensible and cautious. I am merely suggesting that as an admin you should consider a similar strategy for your own good.

While "not using latest tag in docker" is known practice, the problem lies elsewhere.

No, that is it. Period. Don't use it. It has inherent issues. Update to a fixed version when you are happy with it.

Release are releases. Development etc is in github on branches, usually develop. Not in docker images. They are just a snapshot of development. That will not change.

When they feel code is suitable for release they do so - usually following their agile release plans. They release RCs about 10 days prior from the 20th and then a full release on or about the 30th.

This has been going on quite a while now since they went to a rapid release schedule several years back.

A release is zero guarantee of stable. In reality what code is?

It is a release that they consider is OK to go as they have performed some testing and QA. But the risk to upgrade is entirely yours. Do your due diligence. It is why it is stated in the docs NOT to use latest. That is warning enough.

Had I not always tested on test instances AND created snapshots of the production

That is just prudence and good admin.

It is simply the case that most users consider a latest major version being stable.

Assumptions. There are a thousand quotes on their dangers. That is because IME most users don't read enough and make badly informed decisions, usually based on information and sales pitch from companies who should know better.

Please, write some more to help users how to administer a Rocket server and do a PR on the docs repo.

Windows 11

What makes you think that any released version of Windows ever was stable? Who told you that ? Microsoft? Why do they have Enterprise versions where admins can pin releases instead of auto upgrading if they were so solid and stable and reliable? Desktop users dogfood for Enterprise.

release strategy: release early, release quickly,

It is not my choice. It is the way they operate. Understand it and adapt accordingly.

would personally recommend a dev branch to prevent the obvious.

It's here. They just don't build a docker image. You could if you really wanted to - the tools are here.

https://github.com/RocketChat/Rocket.Chat/tree/develop

For further discussion you can get hold of me as reetp in

https://open.rocket.chat/channel/support

Can we now please close comments unless they strictly relate to the bug, and wait for your fixes to land.

Thank you.

[casalsgh]

The internal team still working on a solid fix for it. Expect a new patch 6.9.2 containing the fix to be shared soon.
Adjustments are being made also to prevent such an event from happening again.

[casalsgh]

From reetp as a nice reference -> https://gist.github.com/reetp/ddd0580ab9f9397715da1c14cd85a73c

[casalsgh]

Workspaces impacted should upgrade to the next patches that go out later today (versions 6.5.8, 6.6.10, 6.7.5, 6.8.2 and 6.9.2 will have fix).

[casalsgh]

Folks, Patch released are out and to fix the situation, please upgrade to any of the following versions 6.5.8, 6.6.10, 6.7.5, 6.8.2 or 6.9.2