RocketChat/Rocket.Chat · error · Meteor.Error

error-not-allowed

error-not-allowed

Error message

Not allowed

What it means

Inside starMessage, after the subscription and message existence checks pass, the room is loaded with Rooms.findOneById; a null result throws Meteor.Error('error-not-allowed', 'Not allowed'). The user is subscribed and the message row exists, but the room document itself is gone - an inconsistent state pointing at orphaned data.

Source

Thrown at apps/meteor/server/lib/messaging/stars/starMessage.ts:41

			method: 'starMessage',
			action: 'Message_starring',
		});
	}

	const subscription = await Subscriptions.findOneByRoomIdAndUserId(message.rid, user._id, {
		projection: { _id: 1 },
	});
	if (!subscription) {
		return false;
	}
	if (!(await Messages.findOneByRoomIdAndMessageId(message.rid, message._id))) {
		return false;
	}

	const room = await Rooms.findOneById(message.rid, { projection: { ...roomAccessAttributes, lastMessage: 1 } });

	if (!room) {
		throw new Meteor.Error('error-not-allowed', 'Not allowed', { method: 'starMessage' });
	}

	if (!(await canAccessRoomAsync(room, { _id: user._id }))) {
		throw new Meteor.Error('not-authorized', 'Not Authorized', { method: 'starMessage' });
	}

	if (isTheLastMessage(room, message)) {
		await Rooms.updateLastMessageStar(room._id, user._id, message.starred);
		void notifyOnRoomChangedById(room._id);
	}

	await Apps.self?.triggerEvent(AppEvents.IPostMessageStarred, message, user, message.starred);

	await Messages.updateUserStarById(message._id, user._id, message.starred);

	void notifyOnMessageChange({
		id: message._id,
	});

View on GitHub (pinned to b2c16d5842)

Solutions

  1. Repair the data: remove subscription and message rows whose rid no longer resolves to a room
  2. Re-run room deletion through server methods so the cascade completes
  3. If it reproduces with a live room, inspect the message's rid for typos or corruption

Example fix

// before - stale rows keep the star UI alive, method throws
Meteor.call('starMessage', { rid, _id: messageId, starred: true });

// after - data repair (mongo shell): drop subscriptions orphaned by room deletion
// db.subscriptions.find({ rid: { $nin: db.rooms.distinct('_id') } })
//   .forEach(s => db.subscriptions.deleteOne({ _id: s._id }))
Defensive patterns

Strategy: try-catch

Validate before calling

// Server-side guard before delegating
const room = await Rooms.findOneById(message.rid, { projections: { _id: 1 } });
if (!room) {
  return; // orphaned subscription/message - schedule data repair
}
await starMessage(user, message);

Try / catch

Meteor.call('starMessage', msg, (err) => {
  if (err?.error === 'error-not-allowed' && err.details?.method === 'starMessage') {
    flagRoomAsBroken(msg.rid); // hide room and alert admins about orphaned data
  }
});

Prevention

When it happens

Trigger: Meteor.call('starMessage', ...) where message.rid points at a deleted room while the user's subscription row and the message row still exist - typically after partial deletions, interrupted cleanups, or migration artifacts.

Common situations: Imports/migrations leaving orphaned subscriptions and messages; direct database surgery that dropped rooms without cascading; replication lag in manual ops.

Related errors


AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18). Data as JSON: /api/errors/dc498dbd6cebc88c. Report an issue: GitHub.