Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Dynamic config DELETE should fall back to the default value, not the server.yaml startup value

オープン
  • 何か問題がありますか？
#4,627 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
28/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java
領域
api, backend

調査の方向性

Start from the server-side handling of AlterConfigOpType.DELETE for dynamic cluster configs, and from Admin.alterClusterConfigs() and describeClusterConfigs() as the entry points. Trace where the startup value from server.yaml is kept alongside dynamic overrides. The issue leaves open whether to change DELETE or add a RESET_TO_DEFAULT op, so confirm the direction with a maintainer first. Done means a deleted key reverts to the Fluss default and is no longer listed as DYNAMIC_SERVER_CONFIG, including the same-value case.

索引モデルが issue の本文から書いたものです。

説明

Search before asking
  • I searched in the issues and found nothing similar.
Motivation

Today, Admin.alterClusterConfigs() with AlterConfigOpType.DELETE removes a dynamic override, and the server falls back to the value it read from server.yaml at startup. Only when the key is absent from server.yaml does it fall back to the Fluss default. A startup value cannot be removed through the API at all; only a restart with an edited server.yaml removes it.

This is a problem for tooling that owns server.yaml, such as a Kubernetes operator that renders the file from a custom resource and pushes dynamic keys through the Admin API. When a user removes a dynamic key from the resource, the tool rewrites server.yaml for the next restart, but it has no way to apply the removal to the running servers:

  • If the key was only in server.yaml, there is no override to delete, and the server keeps the old value.
  • If the key was changed since startup, DELETE drops the override, and the server goes back to the old startup value instead of the default.

In both cases the running cluster keeps a value the user removed, and a full rolling restart is the only way to apply a change to a key that is meant to be dynamic.

Example, with kv.snapshot.interval: 10min in server.yaml:

  1. SET kv.snapshot.interval=20min: the server uses 20min.
  2. DELETE kv.snapshot.interval: the server uses 10min again, not the default.
Solution

Make DELETE remove the key's effective value entirely, so the server uses the Fluss default whether or not server.yaml sets the key. describeClusterConfigs() would then list nothing for that key.

If changing DELETE itself is a compatibility concern, an explicit opt-in gives the same result, for example a new AlterConfigOpType such as RESET_TO_DEFAULT, which removes both the override and the startup value of a dynamic key.

Anything else?

A related issue appears in 1.0.0. If an override is set to the same value as the startup value and then deleted, the deletion is skipped and the override stays listed as DYNAMIC_SERVER_CONFIG. The change above would remove that case too.

Willingness to contribute
  • I'm willing to submit a PR!
主要言語
Java
スター
2.2k
フォーク
658
平均マージ
3日 2時間
マージ済み PR（30日）
119

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/fluss のほかの issue

apache/fluss の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。