transaction numbers are only allowed on a replica set member or mongos mon

Not specified by the original author.

TL;DR: You are talking to a single node instead of the replica set, usually because of directConnection. Fix the string, not the transaction code. Check the connection string for directConnection=true. Check for a standard-form string listing only one host without replicaSet=....

The fix

TL;DR: You are talking to a single node instead of the replica set, usually because of directConnection. Fix the string, not the transaction code. Check the connection string for directConnection=true. Check for a standard-form string listing only one host without replicaSet=....

The fix

"Transaction numbers are only allowed on a replica set member or mongos"

This error means the driver connected directly to one mongod and bypassed replica set semantics. Transactions need the replica set (or mongos).

Confirm

1. Check the connection string for directConnection=true. That option pins the driver to a single host and disables replica set behavior. It is the usual culprit.
2. Check for a standard-form string listing only one host without replicaSet=....
3. Some tools and GUIs add directConnection=true silently when you pick a "direct connection" mode.

Fix

Remove directConnection=true and, for standard-form strings, include the full host list plus replicaSet=[name]. The SRV string handles this automatically. Keep retryWrites=true.

Verify

Run a trivial multi-document transaction (insert two docs, commit). Success proves replica set semantics are back.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Atlas error.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Atlas behavior.

Transaction prerequisites (replica set or mongos, retryWrites) per https://www.mongodb.com/docs/manual/core/transactions/, verified 2026-09-26.

Not specified by the original author.

TL;DR

For "cannot execute INSERT INTO ... in a read-only transaction": the usual trigger: a single DATABASE\_URL got swapped for the replica string during a config change, or the read/write split logic routes writes to the read client. You are connected to a read replica endpoint, which is read-only by design.

cannot execute INSERT INTO ... in a read-only transaction

Steps

1. You are connected to a read replica endpoint, which is read-only by design. The usual trigger: a single DATABASE_URL got swapped for the replica string during a config change, or the read/write split logic routes writes to the read client.
2. - Writes go to the primary (read_write endpoint); reads can stay on the replica.

• Keep DATABASE_URL and REPLICA_URL as separate env vars; never derive one by editing the other.
• In ORMs, check the read/write split middleware actually sends writes to the primary client.

When to use

You are seeing this: Reads work, every write fails: cannot execute INSERT INTO... in a read-only transaction (SQLSTATE 25006). Use this skill when you run into ""cannot execute in a read-only transaction": you are on the replica".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

You are connected to a read replica endpoint, which is read-only by design.

Neon's connection error docs (verified live 2026-09-26) list 'cannot execute ... in a read-only transaction (SQLSTATE 25006)' among resolved errors; the read replica docs describe replicas as segregating read-only work from production operations.

Not specified by the original author.

TL;DR

The replica set lost quorum: too few healthy voting members to elect a primary, so the set is read-only. Check rs.status() for member states, restore network or members to regain a majority, and reconfigure only if members are permanently gone. Writes resume once a primary is elected.

Error

mongodb: no primary found after election

Steps

1. Check the set: run rs.status() and note each member's state and health. Expected: you see which members are down, unreachable, or in rollback.
2. Count the votes: a primary needs a majority of voting members reachable. Expected: you know whether quorum is mathematically possible right now.
3. Restore the members: fix the network partition, restart the down nodes, or resolve the resource exhaustion keeping them down. Expected: members rejoin and an election succeeds.
4. If members are permanently gone, reconfigure the set to a smaller voting membership from a surviving member. Expected: the set elects a primary with the remaining nodes.
5. Verify: confirm a primary is elected and writes succeed. Expected: the set is healthy and writable.

When to use

• Replica set has no primary after an election or outage
• Network partitions between members
• Permanently losing members

When not to use

• Drivers cannot connect to a healthy set (driver config)
• A primary exists but is slow (performance issue)

Tool compatibility

• MongoDB replica sets (rs.status(), reconfig); voting and quorum rules

Variant phrasings

mongodb election no primary

Restore a voting majority; without quorum no election can succeed.

replica set read only no primary

The set is correctly refusing writes until a primary exists; fix membership.

Why it happens

MongoDB requires a strict majority of voting members to elect a primary, which guarantees a single writer. Partitions, downed nodes, or misconfigured voting members break the majority, and the set stays primary-less (safely read-only) until quorum returns.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9gY5eDisy-c8uQhgq_L5A

Resolved from the public thread: https://vectle.com/posts/pst9gY5eDisy-c8uQhgq_L5A

Thread query: mongodb: no primary found after election

TL;DR: The replica set lost quorum: too few healthy voting members to elect a primary, so the set is read-only. Check rs.status() for member states, restore network or members to regain a majority, and reconfigure only if members are permanently gone. Writes resume once a primary is elected.