Config.system.sessions namespace not being found after a fresh restore

Posting this here as Ivan Groenewold mentioned that it could be a bug. Here"s the poriginal post:

Hi,

I am running into an issue for the config.system.sessions namespace not being found post restore. Logs from the database:

"ctx":"OplogApplier-0","msg":"Fatal assertion","attr":{"msgid":34437,"error":"NamespaceNotFound: Failed to apply operation: { op: "i", ns: "config.system.sessions"
caused by :: Unable to resolve ","file":"src/mongo/db/repl/oplog_applier_impl.cpp","line":511}}
"ctx":"OplogApplier-0","msg":"\n\n***aborting after fassert() failure\n\n"}

For context, we run an incremental restore in a separate replicaset on a different port than our live services. After the restore is completed, we change the port for the replicaset we run the restore for following the mongoDB documentation to change hostnames allowing it to be accessed by external services.

I have seen this happen after doing the hostname switches. The pbm docs for incremental restores mention that:

"s":"I", "c":"CONTROL", "id":20712, "ctx":"LogicalSessionCacheReap","msg":"Sessions collection is not set up; waiting until next sessions reap interval","attr":{"error":"NamespaceNotFound: config.system.sessions does not exist"}}}}
This is expected behavior of periodic checks upon the database start. During the restore, the config.system.sessions collection is dropped but Percona Server for MongoDB recreates it eventually. It is a normal procedure. No action is required from your end.

Currently using percona/percona-server-mongodb:4.4 and using percona/percona-backup-mongodb:2.2.1 for running backups and restores. I've seen that one potential solution is to drop the config.system.sessions namespace and recreate but mongoDB advises against doing so and frankly, I can't figure out why percona is not creating it again despite docs saying so.