Rocket.Chat 0.67.0 Extraordinary Release

Announcements
1

We just released the first release candidate of version 0.67.0 as an extraordinary release.

This release will not follow our usual release cycle that starts at every 20th of each month with the first release candidate and ends 7 days later with the final release because we are releasing a big change (can be a breaking change for who has custom builds) that will improve the server performance.

The main reason

The reason we are doing that is this Pull Request where we remove the cache layer and back to use the database for all queries. The PR contains a good explanation of the reasons behind the change and the expected results.

We have being working on that for more than 1 month and we used this changes at https://open.rocket.chat many times to check the results that were very good.

The release cycle

Since this will be out of our release process we don’t really have a date for the final release yet, we are targeting the day 20th of this month, but that can change.

The normal release at 20th/27th

This release will not affect the normal release, we will have the candidate of version 0.68.0 at 20th of this month and a final release at 27th which will include the cache removal as well, we could say that version 0.67.0 will be a more long release candidate period for a important part of version 0.68.0.

Breaking changes

If you are running a custom fork you may have problems if you rely on the cache layer or room.usernames

Cache layer

We removed the collection events related to the cache layer, example:

RocketChat.models.Subscriptions.on('changed', ...

RocketChat.models.Subscriptions.on('join:fname:inserted', ...

We removed collection methods getDynamicView, processQueryOptionsOnResult and all the code at file _BaseCache.js

Usernames

We started removing the room.usernames property a long time ago, but we was rebuilding it at the cache layer level, now we are removing it at all for rooms of type p and ‘c’, the direct message rooms still have the property listing the 2 usernames involved.

Regressions and issues

Please refer to the original Pull Request if you have any problem related to this change, we will keep monitoring this PR to check for comments and linked issues.

5 Likes
2

I very much appreciate your effort to invest this architectural effort! I did not like the cache-layer since I first met it :wink:

Also, I have always been surprised to see the members of a room in room.usernames in addition to the concept of subscriptions. Do I assume right that the proper way to determine the users based upon a find on
RocketChat.models.Subscriptions? I have seen the code

const members = RocketChat.models.Subscriptions.findByRoomIdWhenUsernameExists(this._id, {	
			fields: {	
				'u.username': 1	
			}	
		}).fetch().map(s => s.u.username);

in some commit which has been reverted. Why is that obviously not appropriate?

3

That code was an attempt to keep the property usernames as a calculated property where when accessed would find all usernames and return, just to keep compatibility, but it was not possible since the models were trying to set that property what would increase the complexity to make this workaround so we decided to strip off the calculated solution @ojaegle

Now you should find the subscriptions to get the users of a room and we added a property to the room named usersCount to be able to sort rooms by members.

1 Like