Channel names allow case-variant duplicates (e.g., general and General) causing routing conflicts

[sahillllllllll-bit]

Description

Room name validation currently performs a case-sensitive duplicate check in getValidRoomName.
However, routing, mentions, and search treat room names case-insensitively.

Because of this mismatch, channels that differ only by letter casing can be created.

Example:

general
General

Both rooms coexist in the database, but the application resolves them to the same route.

Opening:

/channel/General

redirects to:

/channel/general

This leads to incorrect navigation and mention behavior.

---

Steps to Reproduce

1. Create a channel named general
2. Create another channel named General
3. Both channels are created successfully
4. Visit /channel/General

---

Expected behavior

The second channel creation should be rejected because channel names should be unique regardless of letter casing.

---

Actual behavior

Both channels are created, but routing redirects to the lowercase version, causing inconsistent behavior with navigation, mentions, and search.

---

Impact

• Incorrect channel routing
• Confusing mentions
• Broken navigation for users
• Duplicate logical channels

---

Proposed Solution

Normalize the room name (e.g., lowercase) before duplicate validation to enforce case-insensitive uniqueness.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details of issue `#39156`
gh issue view 39156 --repo RocketChat/Rocket.Chat --json title,body,labels,state,createdAt,author,url,comments

# Check for linked PRs
gh issue view 39156 --repo RocketChat/Rocket.Chat --json comments --jq '.comments[].body' | grep -E '#[0-9]+|/pull/[0-9]+'

Length of output: 2216

---

🏁 Script executed:

#!/bin/bash
# Search for PRs that mention this issue or are related to room name case-sensitivity
gh pr list --repo RocketChat/Rocket.Chat --search "39156" --json number,title,url,state,author --limit 10

# Search for recent PRs related to room name validation or case-sensitivity
gh pr list --repo RocketChat/Rocket.Chat --search "room name case" --json number,title,url,state,author --limit 10

# Search for PRs with getValidRoomName
gh pr list --repo RocketChat/Rocket.Chat --search "getValidRoomName" --json number,title,url,state,author --limit 10

Length of output: 3101

---

🏁 Script executed:

#!/bin/bash
# Fetch PR details
gh pr view 39145 --repo RocketChat/Rocket.Chat --json title,body,files,additions,deletions,changedFiles,state,author,url,comments

# Get the diff of the PR
gh pr diff 39145 --repo RocketChat/Rocket.Chat

Length of output: 13365

---

@sahillllllllll-bit, no, this is definitely not intentional - it's a legitimate bug. The mismatch between case-sensitive validation and case-insensitive routing creates the exact issues you described: routing conflicts, broken navigation, and confusing mentions.

I've reviewed PR #39145 and the approach is correct (normalizing to lowercase before validation), but there's room for optimization in the implementation:

Review of PR #39145

Current Implementation Issue

The code applies .toLowerCase() redundantly in multiple places:

// Line 11: First normalization
slugifiedName = slugifiedName.toLowerCase();

// Line 31: Applied again (redundant)
slugifiedName = cleanName.toLowerCase();

// Line 50: Applied again (redundant) 
const room = await Rooms.findOneByName(slugifiedName.toLowerCase());

// Line 57: Applied again (redundant)
tmpName = `${slugifiedName.toLowerCase()}-${++next}`;

Since slugifiedName is already lowercased at line 11, the subsequent .toLowerCase() calls are unnecessary.

Suggested Optimization

Option 1: Keep only the initial normalization (simplest)

export const getValidRoomName = async (displayName: string, rid = '', options: { allowDuplicates?: boolean } = {}) => {
	let slugifiedName = displayName.toLowerCase(); // Normalize once at the start
	
	if (settings.get('UI_Allow_room_names_with_special_chars')) {
		const cleanName = limax(displayName, { maintainCase: false }); // Use maintainCase: false
		// ... rest of logic
		slugifiedName = cleanName;
	}
	// ... rest remains the same, no additional .toLowerCase() needed
}

Option 2: Normalize after special char processing (if you want to preserve the limax behavior)

export const getValidRoomName = async (displayName: string, rid = '', options: { allowDuplicates?: boolean } = {}) => {
	let slugifiedName = displayName;
	
	if (settings.get('UI_Allow_room_names_with_special_chars')) {
		const cleanName = limax(displayName, { maintainCase: true });
		// ... existing logic
		slugifiedName = cleanName.toLowerCase(); // Normalize once here
	} else {
		slugifiedName = slugifiedName.toLowerCase(); // And once here for the else path
	}
	
	// No additional .toLowerCase() calls needed below
	// Lines 50 and 57 use slugifiedName directly
}

Additional Considerations

1. Database query: Consider if there's a case-insensitive index on the name field in the Rooms collection for performance
2. Migration: Existing rooms with uppercase letters will still exist - consider if a data migration is needed
3. API/UI: Ensure that room creation endpoints properly handle the case normalization and provide clear error messages

The fix correctly addresses the bug, but removing the redundant operations will make the code cleaner and more efficient.

---

🧠 Learnings used

Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:18.785Z
Learning: In Rocket.Chat PR reviews, maintain strict scope boundaries—when a PR is focused on a specific endpoint (e.g., rooms.favorite), avoid reviewing or suggesting changes to other endpoints that were incidentally refactored (e.g., rooms.invite) unless explicitly requested by maintainers.