Mongo 4.2 primary unexpectedly processing ops log entries

hi - we have an 8TB cluster, one primary, and normally two secondaries.

After an unfortunate series of events, we had a primary which was the only member of it’s replica set, while the secondaries were offline rebuilding indices.

Eventually, we observed that one of the secondaries appeared to have recovered, as it was responding on 27017 with no errors of note in it’s logs. The logs had many entries of this form:

2023-08-01T06:09:50.152+0000 I CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to mhost1.foobar.net:27017
2023-08-01T06:09:50.152+0000 I CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to mhost2.foobar.net:27017

Then, the secondary was added back back to the replica set with no voting and no priority. After that, we obseved that the primary had returned to a state where it appears to be processing op log entries from 2 days ago, with many entries of this form:
"I REPL [repl-writer-worker-13] applied op: CRUD"

While the primary is doing that , it’s not accepting connections on 27017. (And meantime, the secondary was failing to establish a connection to the primary, so at this point we’ve shut it down).

Is this expected behavior? Is it possible that even though the secondary had no priority and no voting power, it nevertheless caused the primary to being behaving like a secondary?

i don’t quite get this. the info seems to say that the primary instance is replicating data to the newly added secondary (vote 0 and pri 0). What you mean by “the primay … like a secondary” ?