@Rocky I run 4.0.0. I created mat view with 2 months retention by date column. then I changed it to 6 months. data loaded fine, but after FE leader restart I got all data older then 2 months deleted. DDL looks correct with 6 months. is there any known bug?

This behavior sounds like a metadata persistence or scheduling issue where the background cleanup task did not correctly pick up the updated property after the FE restart, despite the DDL showing the correct value. While there isn't a single "named" bug exactly matching your description in the public tracker for version 4.0.0, there are several related known issues in the 4.x and late 3.5.x branches regarding metadata loss/stale state after FE restarts and Materialized View (MV) TTL logic: 1. Known Metadata Persistence Issues There have been multiple reports of metadata properties being "lost" or reverting to old states after an FE leader restart in early 4.0 versions. A notable example is Issue #66474, where foreign key constraints (and potentially other MV properties) were lost after an FE restart. These issues are generally addressed in patch releases like 4.0.1 and 4.0.2. 2. partition_retention_condition Bugs The

partition_retention_condition

property (introduced in v3.5.0) has had specific bugs related to how it evaluates time-based expressions: * Issue #65575: Specifically addressed failures and incorrect behavior when this condition referenced generated columns or specific expression types. * Scheduling Latency: The background cleaner periodically evaluates these expressions. If you updated the property from 2 months to 6 months, the FE leader restart might have triggered an immediate "catch-up" run of the partition cleaner. If the cleaner thread initialized with a stale version of the MV's metadata before the full image was replayed or if it used a cached value, it could have executed the drop based on the old 2-month threshold. Troubleshooting and Verification To confirm if this is a persistence bug or a scheduling anomaly: 1. Check the DDL again: Run

SHOW CREATE MATERIALIZED VIEW <mv_name>;

now. If it still says

6 months

, the issue is likely in the scheduler/cleaner logic (which might be using a stale internal state). If it somehow reverted to

2 months

in the output, it is a metadata persistence bug. 2. Verify the partitions: Check

information_schema.partitions

or run

SHOW PARTITIONS FROM <mv_name>;

to see if the partitions were physically dropped or just "hidden" from query results (though retention policies usually physically drop them). 3. Recovering Data: Since you are on 4.0.0, you might be able to recover the dropped partitions using the

RECOVER

command if they were dropped within the

catalog_trash_expire_second

window (default is 1 day):

sql
    RECOVER PARTITION <partition_name> FROM <mv_name>;

Recommendation If you can, upgrade to v4.0.2 or later. The 4.0.0 release was the initial major version, and subsequent patches fixed several critical metadata and MV scheduling bugs (such as #71265 and #66474) that could cause exactly this kind of behavior. If the problem persists on a newer version, it is recommended to collect the FE leader logs from the time of the restart and provide them to the community on Slack or GitHub, as this would indicate a regression in how the partition cleaner handles property updates. References • administration/management/FE_configuration.md • release_notes/release-4.0.md