Description

We noticed an issue with how latency is displayed in the HVR Statistics dashboard when replication becomes idle.

While replication is actively processing transactions, latency is reported correctly. However, once the source system becomes inactive and no new transactions are generated, the capture process goes idle and no additional entries are written into the hvr_stats table.

Because of this, the Statistics dashboard continues showing the last recorded latency value for hours until new activity appears again. This gives the impression that replication is still lagging, even though the system is actually fully caught up and simply waiting for new data.

For example:

• Last latency datapoint shown: Apr 30 01:52
• Next datapoint shown: Apr 30 13:30

During this entire period:

• Capture was healthy and idle
• No pending transactions existed
• No new hvr_stats records were written
• The old latency value continued to appear in the graph

This behavior is misleading for monitoring and operational visibility because users may assume replication is delayed or stuck when it is actually idle.

Expected Behavior

When capture is idle and there are no pending transactions, the Statistics dashboard should reflect this correctly.

Possible approaches:

• Write periodic entries into hvr_stats with latency set to 0
• Treat missing datapoints as zero latency during idle periods
• Display an explicit “Idle” state in the Statistics UI

Benefits

This would:

• Provide more accurate latency reporting
• Prevent confusion during low-activity periods
• Reduce unnecessary troubleshooting or false alarms
• Make it easier to distinguish between real lag and idle replication