Summary

The `printSecondaryReplicationInfo()` method in mongosh incorrectly calculates replication lag with inverted operands, resulting in negative lag values when secondaries are behind the primary. This is a regression from the legacy mongo shell behavior.

Environment

• mongosh version: v2.5.8 (bug, likely affects other versions)
• Legacy mongo shell version: v5.0.0 (correct behavior for comparison)
• MongoDB server version: v6.0.26
• Platform: macOS

• Steps to Reproduce

1. Connect to a MongoDB replica set with at least one secondary that is lagging
   2. Run `db.printSecondaryReplicationInfo()` in both legacy mongo shell and mongosh
   3. Compare the output

• Expected Behavior*

When a secondary is behind the primary, the replication lag should be displayed as a positive value indicating seconds/hours behind.

Legacy mongo shell (v5.0.0) - CORRECT:
```
source: localhost:27018
syncedTo: Thu Dec 11 2025 20:55:59 GMT+0530 (IST)
2501 secs (0.69 hrs) behind the primary
```

Actual Behavior

mongosh displays replication lag as a negative value.

mongosh (v2.5.8) - INCORRECT:
```
source: localhost:27018

{   syncedTo: 'Thu Dec 11 2025 20:55:59 GMT+0530 (India Standard Time)',   replLag: '-2511 secs (-0.7 hrs) behind the primary ' }

```

Root Cause

The subtraction order in the lag calculation is inverted.

Legacy mongo shell (CORRECT):
```javascript
// File: src/mongo/shell/db.js, line ~1054
var ago = (startOptimeDate - st) / 1000;
```
Source:[ https://github.com/mongodb/mongo/blob/r5.0.0/src/mongo/shell/db.js#L1054|https://github.com/mongodb/mongo/blob/r5.0.0/src/mongo/shell/db.js#L1054]

mongosh (INCORRECT):
```typescript
// File: packages/shell-api/src/database.ts, line ~1314
const ago = (node.optimeDate - startOptimeDate) / 1000;
```
Source:[ https://github.com/mongodb-js/mongosh/blob/v1.3.1/packages/shell-api/src/database.ts#L1314|https://github.com/mongodb-js/mongosh/blob/v1.3.1/packages/shell-api/src/database.ts#L1314]

Explanation

In a replica set:

• `startOptimeDate` = timestamp of the most recent operation (primary or freshest member)
• `node.optimeDate` = timestamp of the secondary's last replicated operation

Since the secondary is behind, its timestamp is older/smaller:

• Correct: `(primary_time - secondary_time)` = positive lag value
• Incorrect: `(secondary_time - primary_time)` = negative lag value

1.  

Impact:

1. User confusion: Negative lag values are semantically incorrect and confusing
   2. Monitoring tools: Automated monitoring may misinterpret negative values
   3. Inconsistency: Behavior differs from legacy mongo shell, breaking user expectations
   4. Operations: Operators cannot quickly assess replication health at a glance

Severity: Medium - Does not affect actual replication, but significantly impacts monitoring and troubleshooting

1.  

References

• Legacy mongo shell implementation:[ https://github.com/mongodb/mongo/blob/r5.0.0/src/mongo/shell/db.js#L1047-L1063|https://github.com/mongodb/mongo/blob/r5.0.0/src/mongo/shell/db.js#L1047-L1063]
• mongosh implementation (v1.3.1):[ https://github.com/mongodb-js/mongosh/blob/v1.3.1/packages/shell-api/src/database.ts#L1271-L1323|https://github.com/mongodb-js/mongosh/blob/v1.3.1/packages/shell-api/src/database.ts#L1271-L1323]