[FLINK-12064] [core, State Backends] RocksDBKeyedStateBackend snapshot uses incorrect key serializer if reconfigure happens during restore#8076
Conversation
…correct key serializer if reconfigure happens during restore
|
Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community Review Progress
Please see the Pull Request Review Guide for a full explanation of the review process. DetailsThe Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required Bot commandsThe @flinkbot bot supports the following commands:
|
|
Just to clarify: Otherwise, the title / description implies that it is using the wrong key serializer for runtime state access. |
|
Thanks for the fix @carp84. I've verified that the modified tests fail without the fixes to the key serializer access. |
|
@flinkbot approve all |
…ts uses incorrect key serializer if reconfigure happens during restore This closes #8076.
|
Thanks for the review! @tzulitai |
…ts uses incorrect key serializer if reconfigure happens during restore This closes apache#8076.
…ts uses incorrect key serializer if reconfigure happens during restore This closes apache#8076.
What is the purpose of the change
This PR fixes the issue of
RocksDBKeyedStateBackendsnapshot using incorrect key serializer if reconfigured during restore inRocksDBKeyedStateBackendBuilder, which is a regression caused by FLINK-10043. We also reenforce the UT cases to cover the issue scenario.Brief change log
Remove
keySerializerfromAbstractKeyedStateBackendBuilderand usekeySerializerProvider.currentSchemaSerializer()instead inRocksDBKeyedStateBackendBuilder. For the test case part, perform an additional snapshot after state migration.Verifying this change
This change added tests and can be verified as follows:
StateBackendMigrationTestBase, adding an additional snapshot after state migration to verify the snapshot part.Does this pull request potentially affect one of the following parts:
@Public(Evolving): (no)Documentation