RocketChat/Rocket.Chat · warning
Invalid settings found on DB. Deleting them.
Error message
Invalid settings found on DB. Deleting them.
What it means
Logged by settingsRegenerator(), which runs as part of Rocket.Chat startup to validate the Settings MongoDB collection. It queries for documents that are missing ALL of the required structural fields (value, type, public, packageValue, blocked, sorter, i18nLabel) — i.e. completely malformed setting records — and deletes them with Settings.deleteMany. The warning lists the offending _ids so the operator can trace where they came from. After deletion the settings are regenerated from the code-defined registry on next startup.
Source
Thrown at apps/meteor/server/lib/settingsRegenerator.ts:26
export async function settingsRegenerator() {
const invalidSettings = await Settings.find(
{
// Putting the $and explicit to ensure it's "intentional"
$and: [
{ value: { $exists: false } },
{ type: { $exists: false } },
{ public: { $exists: false } },
{ packageValue: { $exists: false } },
{ blocked: { $exists: false } },
{ sorter: { $exists: false } },
{ i18nLabel: { $exists: false } },
],
},
{ projection: { _id: 1 } },
).toArray();
if (invalidSettings.length > 0) {
logger.warn({
msg: 'Invalid settings found on DB. Deleting them.',
settings: invalidSettings.map(({ _id }) => _id),
});
await Settings.deleteMany({ _id: { $in: invalidSettings.map(({ _id }) => _id) } });
// No need to notify listener
} else {
logger.info('No invalid settings found on DB.');
}
}
View on GitHub (pinned to b2c16d5842)
Solutions
- Note the setting _ids printed in the warning and confirm none of them are entries you actually need — they were non-functional anyway (no value, no type).
- Restart the server once more: the deleted stubs are regenerated from the code-defined defaults in the settings registry.
- Find and stop whatever wrote the malformed documents (custom app, provisioning script, manual mongo insert) so they do not reappear.
- If the warnings recur every startup, inspect the Settings collection (db.Settings.find({value: {$exists: false}, type: {$exists: false}, ...}) ) and take a backup before letting the regenerator run again.
Example fix
// before: a script inserting a placeholder setting doc with no fields
db.Settings.insertOne({ _id: 'My_Custom_Setting' }); // triggers the warning on next startup
// after: insert a fully-formed setting document
db.Settings.insertOne({
_id: 'My_Custom_Setting',
value: 'hello',
type: 'string',
public: false,
packageValue: 'hello',
blocked: false,
sorter: 0,
i18nLabel: 'My_Custom_Setting',
}); Defensive patterns
Strategy: validation
Validate before calling
// Run before/at startup to see which docs the regenerator will delete
const invalid = db.Settings.find({
$and: [
{ value: { $exists: false } },
{ type: { $exists: false } },
{ public: { $exists: false } },
{ packageValue: { $exists: false } },
{ blocked: { $exists: false } },
{ sorter: { $exists: false } },
{ i18nLabel: { $exists: false } },
],
}, { _id: 1 }).toArray();
printjson(invalid); // empty array => warning will not fire Prevention
- Never insert placeholder documents into the Settings collection; always include value, type, public, packageValue, blocked, sorter and i18nLabel.
- Take a mongodump before major upgrades so settings deleted by the regenerator are recoverable.
- Watch startup logs for the warning after restoring backups or running custom provisioning scripts, and fix the writer, not just the data.
When it happens
Trigger: On every server startup, settingsRegenerator() finds at least one document in the Settings collection missing every required field ($exists: false for value, type, public, packageValue, blocked, sorter, i18nLabel). Typical producers: an interrupted insert/partial write, manual mongo shell inserts of stub documents, a bot or app writing placeholder setting docs, or a restored/damaged database.
Common situations: Upgrading very old or community-forked installations whose settings documents have drifted from the current schema; restoring a backup taken mid-write; running scripts that pre-created empty setting documents; Mongo replica failover leaving partial documents. Operators usually see this once after such an event and never again.
Related errors
- Invalid MONGO_OPTIONS environment variable: must be valid JS
- Error dropping redundant indexes, continuing...
- Not migrating, control is locked. Will retry.
- The setting "${id}" is not readable.
- Method not implemented.
AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18).
Data as JSON: /api/errors/e4cf45fa456aa23a.
Report an issue: GitHub.