docs: document server.readinessHAMaxLag setting

_typos.toml

@@ -1,2 +1,3 @@
 [default.extend-words]
 hel = "hel"
+AKS = "AKS"

src/main/asciidoc/how-to/operations/kubernetes.adoc

@@ -482,7 +482,7 @@ readinessProbe:
 ====
 Prefer the dedicated liveness endpoint `/api/v1/health` for the liveness probe: it never reports a busy state, so a warming-up node is not restarted. Keep `/api/v1/ready` for the readiness probe. The chart's default value tables below reflect the chart's current defaults; override `livenessProbe.httpGet.path` to `/api/v1/health` as shown above. See <<observability-health,Health probes>>.
 
-On a High Availability cluster, set `arcadedb.server.readinessRequiresHA=true` (env `ARCADEDB_SERVER_READINESSREQUIRESHA=true`) to withhold traffic from a node until it has joined the Raft group.
+On a High Availability cluster, set `arcadedb.server.readinessRequiresHA=true` (env `ARCADEDB_SERVER_READINESSREQUIRESHA=true`) to withhold traffic from a node until it has joined the Raft group and, once joined, until it is a member of the current Raft configuration and has caught up to within `arcadedb.server.readinessHAMaxLag` log entries (default `100`, env `ARCADEDB_SERVER_READINESSHAMAXLAG`) of the commit index. This keeps a restarted follower with a wiped or lagging log out of Service endpoints during a rolling update, so the write quorum is not dropped.
 ====
 
 [[kubernetes-values-autoscaling]]

src/main/asciidoc/how-to/operations/observability.adoc

@@ -268,7 +268,7 @@ On a High Availability cluster you can make readiness reflect Raft membership so
 arcadedb.server.readinessRequiresHA=true
 ----
 
-When this flag is `true` and HA is active, `/api/v1/ready` returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected, then `204`. The default (`false`) preserves current readiness behavior. See <<kubernetes,Kubernetes deployment>> for the full StatefulSet example.
+When this flag is `true` and HA is active, `/api/v1/ready` returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected. Once a leader is known, a second gate checks that the node is a member of the current Raft configuration and, for a follower, that it has caught up to within `arcadedb.server.readinessHAMaxLag` log entries (default `100`) of the commit index; until then it keeps returning `503` (`Node is not yet in the Raft configuration or has not caught up`). Only then does it return `204`. This prevents a (re)joined follower with a wiped or lagging log from being marked ready mid-catch-up, which would otherwise let a rolling restart drop the write quorum. The default (`false` for `readinessRequiresHA`) preserves current readiness behavior. See <<kubernetes,Kubernetes deployment>> for the full StatefulSet example.
 
 ===== Further reading
 

src/main/asciidoc/reference/http-api/http.adoc

@@ -257,7 +257,7 @@ Responses:
 * https://httpstatuses.io/204[`204`] OK -- server is `ONLINE`
 * https://httpstatuses.io/503[`503`] server not started yet
 
-When `arcadedb.server.readinessRequiresHA=true` and HA is active, readiness additionally requires the node to have joined the Raft group: it returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected. The default (`false`) preserves the behavior above. See <<observability-health,Health probes>>.
+When `arcadedb.server.readinessRequiresHA=true` and HA is active, readiness additionally requires the node to have joined the Raft group: it returns `503` (`Node has not yet joined the Raft group`) until a leader has been elected. Once a leader is known, a second gate requires the node to be a member of the current Raft configuration and, for a follower, to have replayed the committed log to within `arcadedb.server.readinessHAMaxLag` entries of the commit index; until then it returns `503` (`Node is not yet in the Raft configuration or has not caught up`). This keeps a (re)joined follower with a wiped or lagging log out of traffic during a rolling restart, so the write quorum is not dropped. The default (`false` for `readinessRequiresHA`) preserves the behavior above. See <<observability-health,Health probes>>.
 
 Example:
 

src/main/asciidoc/reference/settings.adoc

@@ -209,6 +209,7 @@ The following plugins are available for ArcadeDB Server:
 |`server.saltIterations`|Number of iterations to generate the salt or user password. Changing this setting does not affect stored passwords|Integer|65536
 |`server.eventBusQueueSize`|Size of the queue used as a buffer for unserviced database change events.|Integer|1000
 |`server.readinessRequiresHA`|When true and HA is active, `/api/v1/ready` also requires the node to have joined the Raft group (a leader has been elected). Default false preserves current readiness behavior. See <<observability-health,Health probes>>. _(Available since v26.7.1)_|Boolean|false
+|`server.readinessHAMaxLag`|When `server.readinessRequiresHA` is true, the maximum number of Raft log entries a follower may lag behind the commit index (`commitIndex - lastAppliedIndex`) and still report Ready. Keeps `/api/v1/ready` returning 503 until a (re)joined follower has replayed the committed log, so a rolling restart does not drop the write quorum. See <<observability-health,Health probes>>. _(Available since v26.7.1)_|Long|100
 |`server.logFormat`|Console log format: `text` (default, human-readable) or `json` (one JSON object per line with correlation fields). See <<observability-logging,Structured logging>>. _(Available since v26.7.1)_|String|text
 |`server.logIncludeTrace`|In text log mode, append `[traceId=...]` to each line while a trace is active. Default false preserves current text output. _(Available since v26.7.1)_|Boolean|false
 |`server.grpcQueryMaxResultRows`|Hard ceiling on the number of rows the gRPC unary `ExecuteQuery` materializes. A request limit at or below this cap is honored; a result that would exceed it fails the call with `RESOURCE_EXHAUSTED` (consistent with the `StreamQuery` `MATERIALIZE_ALL` path) rather than silently truncating, and a client cannot bypass it with a larger limit. Bounds heap usage and protects against limitless-query denial-of-service. The default is lower than `server.grpcStreamMaxMaterializedRows` because the unary response is built and returned as a single gRPC message (also bounded by the max message size), whereas `StreamQuery` emits incrementally. Set to `-1` or `0` for unlimited (removes the DoS protection). _(Available since v26.7.1)_|Integer|100000