fix: update cached setting immediately at the time of updating the db

[debdutdeb]

Proposed changes (including videos or screenshots)

Refreshing cache was depending on changestream, as the update in SettingRegistry rounds back through oplog to our watchers, then some listener.

Problem was that in such a case if anything asks for those setting values BEFORE oplog has got back (slow mongo, or slow instance/server) or we have processed the update, they'll get an old value, not the one intended. This becomes a problem when and if an initialization can't be changed on the fly, and restart will be required to use the right value.

The behavior would be noticed when the setting has already been inserted once with one value, before using OVERWRITE_SETTING_.+

IIUC, now, we'd have to add listener callbacks (watch, watchMultiple, etc) BEFORE settingRegistry.add, so that the callbacks actually get called, as they are indeed changes to track and behave to, but then even inserts will be tracked

We are discussing if this solution makes sense.

Issue(s)

Steps to test or reproduce

For a clearer visible example, remove Site_Url record from db, unset OVERWRITE_SETTING_Site_Url if you already have one, let the server start and insert the default record.

Now stop the server, set the OVERWRITE_.. start the server and notice the startup ascii banner showing old siteurl (:3000) not the new one.

Further comments

CORE-517

[dionisio-bot]

Looks like this PR is not ready to merge, because of the following issues:

• This PR is targeting the wrong base branch. It should target 6.11.0, but it targets 6.10.0

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

[changeset-bot]

🦋 Changeset detected

Latest commit: 67faa99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 32 packages

Name	Type
@rocket.chat/meteor	Patch
@rocket.chat/core-typings	Patch
@rocket.chat/rest-typings	Patch
@rocket.chat/apps	Patch
@rocket.chat/core-services	Patch
@rocket.chat/cron	Patch
@rocket.chat/fuselage-ui-kit	Patch
@rocket.chat/gazzodown	Patch
@rocket.chat/livechat	Patch
@rocket.chat/model-typings	Patch
@rocket.chat/ui-contexts	Patch
@rocket.chat/account-service	Patch
@rocket.chat/authorization-service	Patch
@rocket.chat/ddp-streamer	Patch
@rocket.chat/omnichannel-transcript	Patch
@rocket.chat/presence-service	Patch
@rocket.chat/queue-worker	Patch
@rocket.chat/stream-hub-service	Patch
@rocket.chat/api-client	Patch
@rocket.chat/license	Patch
@rocket.chat/omnichannel-services	Patch
@rocket.chat/pdf-worker	Patch
@rocket.chat/presence	Patch
rocketchat-services	Patch
@rocket.chat/ddp-client	Patch
@rocket.chat/uikit-playground	Patch
@rocket.chat/models	Patch
@rocket.chat/ui-avatar	Patch
@rocket.chat/ui-client	Patch
@rocket.chat/ui-video-conf	Patch
@rocket.chat/web-ui-registration	Patch
@rocket.chat/instance-status	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 56.71%. Comparing base (eb5f93c) to head (67faa99).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #32541      +/-   ##
===========================================
- Coverage    56.73%   56.71%   -0.03%     
===========================================
  Files         2498     2495       -3     
  Lines        55385    55352      -33     
  Branches     11455    11448       -7     
===========================================
- Hits         31424    31394      -30     
- Misses       21256    21259       +3     
+ Partials      2705     2699       -6     

Flag	Coverage Δ
e2e	56.46% <ø> (-0.04%)	⬇️
unit	71.94% <100.00%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

[MarcosSpessatto]

Tested it locally using the use case you mentioned. I think I found a possible issue. I was able to reproduce following the step-by-step, but after running the steps, I started the server again without the OVERWRITE env var, and the value is not being updated anymore (to the default one). I'm not sure if this is the expected behavior though.

Also, we need to add a changeset to the PR.

[debdutdeb]

@MarcosSpessatto I believe expected, as with OVERWRITE we updated the setting record. I didn't change any code related to that.