1996fanrui opened a new pull request, #23987: URL: https://github.com/apache/flink/pull/23987
## What is the purpose of the change Some state backend and checkpoint related options don't set the default value directly, but but they implement default value based on code. Such as: - execution.checkpointing.tolerable-failed-checkpoints: https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#execution-checkpointing-tolerable-failed-checkpoints - state.backend.type : https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#state-backend-type ### Option1 execution.checkpointing.tolerable-failed-checkpoints doesn't have default value, but CheckpointConfig#getTolerableCheckpointFailureNumber calls configuration.getOptional(ExecutionCheckpointingOptions.TOLERABLE_FAILURE_NUMBER).orElse(0). It means the 0 is default value of execution.checkpointing.tolerable-failed-checkpoints. ### Option2 state.backend.type does't have default value, but StateBackendLoader#loadFromApplicationOrConfigOrDefaultInternal calls loadStateBackendFromConfig(config, classLoader, logger). When the return value is null, Flink will consider the hashmap as the default state backend. I checked all callers of StateBackendLoader#loadStateBackendFromConfig, if we change the default value of state.backend.type to hashmap. All of them work well. ### Why set the default value directly is fine? - From user side, it's clearer. - From flink developers or maintainers side, it's easy to maintain. ## Brief change log Adding the default value for them: - execution.checkpointing.tolerable-failed-checkpoints: 0 - state.backend.type: hashmap Note: this PR added the default value, but the behaviour is absolutely same with old one, so it doesn't introduce any effect for users. ## Verifying this change This change is a trivial rework / code cleanup without any test coverage. ## Does this pull request potentially affect one of the following parts: - Dependencies (does it add or upgrade a dependency): no - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no - The serializers: no - The runtime per-record code paths (performance sensitive): no - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no - The S3 file system connector: no ## Documentation - Does this pull request introduce a new feature? no -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org