Startup: transient Mongo SSLHandshakeFailed bursts on plain MongoDB (8.1.1 + Mongo 8.2.4)

Description

After upgrading to Rocket.Chat 8.1.1 (with MongoDB 8.2.4), we consistently see a burst of MongoDB log entries during Rocket.Chat startup:

• codeName: "SSLHandshakeFailed"
• errmsg: "SSL handshake received but server is started without SSL support"

This appears even though Mongo is configured for plain TCP (no TLS), and Rocket.Chat is using non-TLS Mongo URLs.

Environment

• Rocket.Chat: 8.1.1
• MongoDB: 8.2.4
• Deployment: rootful Podman Quadlet on AlmaLinux 9
• MONGO_URL=mongodb://mongodb:27017/rocketchat?replicaSet=rs0
• MONGO_OPLOG_URL=mongodb://mongodb:27017/local?replicaSet=rs0

Observed behavior

At startup, Mongo logs show mixed connection patterns from Rocket.Chat container IP:

• normal driver metadata (nodejs|Meteor) to Mongo
• interleaved SSL handshake attempts, resulting in SSLHandshakeFailed

Example Mongo log line:

{"error":{"code":141,"codeName":"SSLHandshakeFailed","errmsg":"SSL handshake received but server is started without SSL support"},"remote":"10.89.9.11:xxxxx"}

Important detail

The remote IP that triggers SSL handshake errors is the same Rocket.Chat app container IP in the shared network.

Impact

• Rocket.Chat eventually starts and works.
• But this produces noisy logs and makes TLS-related monitoring/alerts unreliable.

Timing pattern

• Errors occur in a burst during startup.
• After startup stabilizes, no new SSLHandshakeFailed entries are seen in short windows (e.g. last 1 minute).

Question

Is this expected in 8.1.1 startup flow (e.g. a transient TLS probe/attempt by one of the internal DB clients), or an unintended behavior/regression?

If expected, can it be suppressed/disabled? If not expected, happy to provide additional diagnostics.

Begin with Rocket.Chat 8.1.1 startup using the supplied MONGO_URL and MONGO_OPLOG_URL against MongoDB 8.2.4, and inspect the startup database-client connection paths that could issue TLS handshakes. Reproduce under the stated rootful Podman/AlmaLinux setup and compare Mongo logs; done means the source is identified and the transient SSLHandshakeFailed burst is either removed or its expected suppression or configuration is documented.