Thanks Sai Krishna for sharing the comments. > Worth pinning down though: is "last changed" the line or the file? the line.
> The plain fallbacks that are old names, s3.access.key, web.address, > schema-registry.url, point at keys that are not themselves deprecated, > so the rule never drops them, and they have never warned anyone either. > Could they be converted to withDeprecatedKeys first, so the clock > starts? It's tough to say in my limited reading. It depends on the specific scenario. If withFallbackKey itself points to some keys that have already expired or been removed, then deleting the corresponding keys is feasible. However, if accurate historical context or the conclusions of a risk assessment cannot be found within a short period of time, perhaps leaving it as is might be one of the best options. Thanks. Yuepeng Pan Krishna Sai <[email protected]> 于2026年9月14日周一 10:24写道： > Hi Yuepeng, > > Yes, that is what I meant. > > I tried to break the 2025 cutoff and could not. The keys I checked land > where you would want them: the jobmanager.web.* keys in RestOptions last > changed in September 2024, and state.backend.local-recovery has been > deprecated since 1.20 with its declaration from 2024. Both stay in > scope. > > Worth pinning down though: is "last changed" the line or the file? They > diverge. RestOptions.java was last touched in February 2026, but its > deprecated-key lines have not changed since September 2024. File-level > would drop the jobmanager.web.* keys, line-level keeps them. > > The plain fallbacks that are old names, s3.access.key, web.address, > schema-registry.url, point at keys that are not themselves deprecated, > so the rule never drops them, and they have never warned anyone either. > Could they be converted to withDeprecatedKeys first, so the clock > starts? > > I can add a "first release deprecated" column from the release tags if > that is useful as a cross-check. > > One for the per-occurrence check: kubernetes.pod-template-file is > deprecated on one option and a plain fallback on two others, so the same > key reads differently depending on the call site. FLINK-40639. > > Best regards, > Sai Krishna Sepuri > > On Sun, Sep 13, 2026 at 8:16 PM Yuepeng Pan <[email protected]> wrote: > > > > Thanks Rui and Sai Krishna. > > > > Sai Krishna, I hope I've understood the point you were emphasizing: the > > entries listed in the document should be treated only as a candidate > target > > set — we should not assume that every item in it will end up having its > > deprecated or fallback keys removed. > > > > I also agree that the two cases need to be separated. Options declared > via > > withDeprecatedKeys exist purely for backward compatibility, whereas some > > withFallbackKeys call sites are exactly the case you described: two > > actively supported options referencing each other. Those should be left > > untouched. > > > > With that in mind, here is a first attempt at defining the scope and the > > risk controls for this work: > > > > - Target scope > > The configuration options collected in the document form the candidate > > target set. > > We narrow this down to options whose withDeprecatedKeys / > withFallbackKeys > > declarations were last changed before 2025 — the cutoff being motivated > by > > Flink 2.0 having been released in March 2025. > > - Risk control > > For options that use withFallbackKeys without setting > > FallbackKey.isDeprecated, we verify each occurrence individually. We only > > drop a fallback declaration when the key it points to is itself > deprecated; > > cross-option defaults between two supported options stay as they are. > > > > Looking forward to more ideas about it. > > > > Best regards, > > Yuepeng Pan > > > > > > > > Krishna Sai <[email protected]> 于2026年9月13日周日 14:38写道： > > > > > Hi Yuepeng, Rui, > > > > > > Thanks for the inventory. This is a cleanup I'd like to see too. > > > > > > One question: does the doc separate withDeprecatedKeys from > > > withFallbackKeys? Only the first sets FallbackKey.isDeprecated, and > > > Configuration#loggingFallback branches on it, so a deprecated key logs > > > WARN while a plain fallback logs INFO. > > > > > > It matters because most withFallbackKeys sites on master (e01bbca) are > > > not old names at all. rest.address falls back to > jobmanager.rpc.address, > > > taskmanager.slot.timeout to pekko.ask.timeout, process.*.working-dir to > > > process.working-dir. Those are cross-option defaults, and removing them > > > would change behaviour for users who never set a deprecated key. > > > > > > A few really are old names, just declared as plain fallbacks: > > > s3.access.key, s3.secret.key, s3.path.style.access, web.address behind > > > rest.bind-address, and schema-registry.url / .subject / .schema in > > > avro-confluent. Those never logged a deprecation warning, only an INFO > > > line calling them a supported fallback. Does the "deprecated before > > > 1.20.0" reasoning still cover keys that were never announced as > > > deprecated, or should they be marked deprecated first and removed a > > > release later? > > > > > > I'm a contributor, not a committer, so this is just input. I can help > > > work through the list if that's useful. > > > > > > Best regards, > > > Sai Krishna Sepuri > > > >
