[
https://issues.apache.org/jira/browse/FLINK-24858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448633#comment-17448633
]
Fabian Paul commented on FLINK-24858:
-------------------------------------
Fixed:
* master 601ef3b3bce040264daa3aedcb9d98ead8303485
* release-1.14 564dee0752619ecb739b4bee1cacba856ea53bac
> TypeSerializer version mismatch during eagerly restore
> ------------------------------------------------------
>
> Key: FLINK-24858
> URL: https://issues.apache.org/jira/browse/FLINK-24858
> Project: Flink
> Issue Type: Bug
> Components: API / Type Serialization System
> Affects Versions: 1.14.0, 1.13.3, 1.15.0
> Reporter: Fabian Paul
> Assignee: Fabian Paul
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.15.0, 1.14.1
>
>
> Currently, some of our TypeSerializer snapshots assume information about the
> binary layout of the actual data rather than only holding information about
> the TypeSerialzer.
> Multiple users ran into this problem
> i.e.[https://lists.apache.org/thread/4q5q7wp0br96op6p7f695q2l8lz4wfzx|https://lists.apache.org/thread/4q5q7wp0br96op6p7f695q2l8lz4wfzx]
> {quote}This manifest itself when state is restored egarly (for example an
> operator state) but, for example a user doesn't register the state on their
> intializeState/open,* and then a checkpoint happens.
> The result is that we will have elements serialized according to an old
> binary layout, but our serializer snapshot declares a new version which
> indicates that the elements are written with a new binary layout.
> The next restore will fail.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
