YSQL Follower Reads: Missing Configurable Replication Lag Threshold

When using YSQL follower reads in YugabyteDB, the goal is to achieve read scaling while maintaining a predictable bound on data staleness.

The current implementation relies on an internal lag heuristic to decide when to redirect a follower‑read query to the leader, but this threshold is not exposed as a configurable GUC or visible metric, leaving operators unable to guarantee a maximum staleness or anticipate fallback behavior.

What is the internal lag threshold value that triggers fallback to the leader? Is there a way to expose or tune this threshold via a GUC, admin command, or observable metric? Can operators rely on any existing statistic to predict when a follower‑read query will be served by a follower versus the leader?