This is an automated email from the ASF dual-hosted git repository.
rkhachatryan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/flink.git
The following commit(s) were added to refs/heads/master by this push:
new 3775f878047 [hotfix][docs] Add feature-flag review guidelines to
AGENTS.md
3775f878047 is described below
commit 3775f878047fcb3dff7577d466cae9576f338a6e
Author: Roman Khachatryan <[email protected]>
AuthorDate: Thu Aug 6 18:30:43 2026 +0200
[hotfix][docs] Add feature-flag review guidelines to AGENTS.md
Add two code review checks: logging the resolved state of a new
feature flag at INFO level, and considering (or requiring, for risky
changes) hiding non-trivial changes behind a feature flag.
---
AGENTS.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/AGENTS.md b/AGENTS.md
index 5a9b127f925..b21b1b52ea0 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -313,6 +313,9 @@ When reviewing a PR or diff against this repo:
- Flag comments that are obvious (restate what the code already says) or
overly verbose.
- In test code, look for potential flakiness — e.g. `Thread.sleep` used
outside a retry/poll loop, or similar timing-dependent, non-deterministic
patterns. Where applicable, suggest clock injection (e.g. a manually-advanced
`Clock`/`ManualClock`) instead of relying on wall-clock time, or waiting for
the actual condition in a loop with a timeout, for deterministic tests.
- Check that each commit message conforms to Flink conventions: it must start
with `[FLINK-XXXX]` or `[hotfix]`, and must specify a subsystem/component (e.g.
`[FLINK-XXXX][runtime] Description`).
+- If a change introduces a new feature controlled by a config option/flag,
check that the resolved state (enabled/disabled, and the effective value) is
logged at INFO level when the feature initializes/activates.
+- Consider whether a change should be hidden behind a feature flag, especially
if it's non-trivial (touches core paths, changes default behavior, or is hard
to reason about in isolation). This is mandatory if the change is risky
(correctness, performance, backward-compatibility, or data-safety risk) and no
flag/kill-switch already exists.
+- For changes to configuration options, check if the corresponding
documentation has been regenerated (this should be covered by tests but
flagging it earlier speeds up development)
## Boundaries
