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 >
