Skip to content

feat(helm): expose readinessHAMaxLag for HA readiness catch-up gate#15

Merged
robfrank merged 1 commit into
mainfrom
feat/readiness-ha-max-lag
Jul 1, 2026
Merged

feat(helm): expose readinessHAMaxLag for HA readiness catch-up gate#15
robfrank merged 1 commit into
mainfrom
feat/readiness-ha-max-lag

Conversation

@robfrank

@robfrank robfrank commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Summary

  • ArcadeDB #4846 adds SERVER_READINESS_HA_MAX_LAG (arcadedb.server.readinessHAMaxLag, default 100), gating /api/v1/ready on Raft log catch-up in addition to the existing leader-known check.
  • Wires the new knob through as observability.health.readinessHAMaxLag, emitted alongside -Darcadedb.server.readinessRequiresHA=true (a no-op upstream unless that flag is set).
  • No chart version bump: 26.7.1 hasn't been released yet, so this rides along in the same unreleased version as the observability feature (#4463) it extends.

Test plan

  • helm unittest . — 164/164 passing (3 new cases: default emission, override, and absence when readinessRequiresHA is false)
  • helm lint . — clean

…ArcadeDB #4846)

ArcadeDB now gates /api/v1/ready on Raft log catch-up via SERVER_READINESS_HA_MAX_LAG,
in addition to the existing readinessRequiresHA leader check. Wire the new
observability.health.readinessHAMaxLag value through to
-Darcadedb.server.readinessHAMaxLag so operators can tune the follower lag bound.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces the observability.health.readinessHAMaxLag configuration parameter to the ArcadeDB Helm chart, allowing users to specify the maximum Raft log lag for a follower to be considered ready. The review feedback points out a potential issue where a null or omitted value could lead to invalid JVM arguments, and suggests a robust template condition to safely handle defaults while preserving 0 as a valid value.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

{{- end }}
{{- if $health.readinessRequiresHA }}
- -Darcadedb.server.readinessRequiresHA=true
- -Darcadedb.server.readinessHAMaxLag={{ $health.readinessHAMaxLag }}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If observability.health.readinessHAMaxLag is omitted or set to null in a user's custom values, rendering {{ $health.readinessHAMaxLag }} directly will result in an empty or <nil> value in the JVM arguments, which can cause startup or parsing failures. Additionally, using a simple default 100 helper would incorrectly override a valid 0 value (since 0 is falsy in Go templates). To handle this robustly, we can define a default fallback that preserves 0 as a valid lag limit.

- -Darcadedb.server.readinessHAMaxLag={{ if or $health.readinessHAMaxLag (eq $health.readinessHAMaxLag 0) (eq $health.readinessHAMaxLag 0.0) }}{{ $health.readinessHAMaxLag }}{{ else }}100{{ end }}

@robfrank robfrank merged commit fd8dfc2 into main Jul 1, 2026
3 checks passed
@robfrank robfrank deleted the feat/readiness-ha-max-lag branch July 1, 2026 12:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant