[
https://issues.apache.org/jira/browse/FLINK-34271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812608#comment-17812608
]
Dawid Wysakowicz commented on FLINK-34271:
------------------------------------------
> But we don’t have tests to cover potential changes about json plan , right?
I'll need to double check if we need that check. After all we don't necessarily
need to maintain exactly the same plan, but we want to make sure the job can be
restored.
> I think the current tests in RestoreTestBase could be modified to regenerate
> a new savepoint metadata as needed every time
That's not an option. We must test with a savepoint from an older version.
That's the entire idea of backwards compatibility.
> Fix the potential failure test about
> GroupAggregateRestoreTest#AGG_WITH_STATE_TTL_HINT
> --------------------------------------------------------------------------------------
>
> Key: FLINK-34271
> URL: https://issues.apache.org/jira/browse/FLINK-34271
> Project: Flink
> Issue Type: Bug
> Components: Table SQL / Planner
> Reporter: xuyang
> Assignee: xuyang
> Priority: Major
> Labels: pull-request-available
>
> The underlying reason is that a previous PR introduced a test with state TTL
> as follows in the SQL:
> {code:java}
> .runSql(
> "INSERT INTO sink_t SELECT /*+ STATE_TTL('source_t' = '4d') */"
> + "b, "
> + "COUNT(*) AS cnt, "
> + "AVG(a) FILTER (WHERE a > 1) AS avg_a, "
> + "MIN(c) AS min_c "
> + "FROM source_t GROUP BY b"){code}
> When the savepoint metadata was generated for the first time, the metadata
> recorded the time when a certain key was accessed. If the test is rerun after
> the TTL has expired, the state of this key in the metadata will be cleared,
> resulting in an incorrect test outcome.
> To rectify this issue, I think the current tests in RestoreTestBase could be
> modified to regenerate a new savepoint metadata as needed every time.
> However, this seems to deviate from the original design purpose of
> RestoreTestBase.
> For my test, I will work around this by removing the data
> "consumedBeforeRestore", as I am only interested in testing the generation of
> an expected JSON plan.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
