[BUG] Week-Partitioned Materialized Views Fail to Refresh in 3.5.0+

## Bug Description

Materialized views partitioned by `date_trunc('week', column_name)` fail to refresh in StarRocks 3.5.0 and later versions. This issue does not occur in versions 3.4.9 and earlier. Day and month partitioning work correctly in all versions.

## Affected Versions

**Working:**
- StarRocks 3.3.18
- StarRocks 3.4.8
- StarRocks 3.4.9

**Broken:**
- StarRocks 3.5.0
- StarRocks 3.5.6

## Steps to Reproduce

### 1. CREATE TABLE

```sql
CREATE TABLE test_base_table (
    id BIGINT,
    dt DATETIME
)
DUPLICATE KEY(id)
PARTITION BY date_trunc('day', dt)
DISTRIBUTED BY HASH(id) BUCKETS 10;
```

### 2. INSERT INTO

```sql
INSERT INTO test_base_table VALUES
    (1, '2025-11-03 10:00:00'),
    (2, '2025-11-05 14:30:00'),
    (3, '2025-11-09 23:59:59'),
    (4, '2025-11-10 00:00:00'),
    (5, '2025-11-11 12:56:04'),
    (6, '2025-11-15 18:20:00'),
    (7, '2025-11-17 00:00:00'),
    (8, '2025-11-20 09:15:00'),
    (9, '2025-11-23 16:45:00');
```

### 3. CREATE MATERIALIZED VIEW

```sql
CREATE MATERIALIZED VIEW test_week_mv
PARTITION BY date_trunc('week', dt)
DISTRIBUTED BY HASH(id) BUCKETS 10
REFRESH ASYNC
AS
SELECT
    id,
    dt,
    date_trunc('week', dt) AS week_start
FROM test_base_table;
```

### 4. REFRESH MATERIALIZED VIEW

```sql
REFRESH MATERIALIZED VIEW test_week_mv;
```

### 5. SELECT to check status

```sql
SELECT * FROM information_schema.task_runs
WHERE task_name LIKE '%test_week_mv%'
ORDER BY create_time DESC
LIMIT 1\G
```

## Expected Behavior

The materialized view should refresh successfully, as it does in StarRocks 3.4.9 and earlier versions.

## Real Behavior

The refresh fails with the following complete error:

```
*************************** 1. row ***************************
     QUERY_ID: 503a03f6-cac6-11f0-ba18-8207271e064d
    TASK_NAME: mv-15229
  CREATE_TIME: 2025-11-26 12:49:14
  FINISH_TIME: 2025-11-26 12:49:17
        STATE: FAILED
      CATALOG: default_catalog
     DATABASE: teste
   DEFINITION: insert overwrite `test_week_mv` SELECT `teste`.`test_base_table`.`id`, `teste`.`test_base_table`.`dt`, date_trunc('week', `teste`.`test_base_table`.`dt`) AS `week_start` FROM `teste`.`test_base_table`
  EXPIRE_TIME: 2025-12-03 12:49:14
   ERROR_CODE: -1
ERROR_MESSAGE: Refresh mv test_week_mv failed after 1 times, try lock failed: 0, error-msg : com.starrocks.sql.common.DmlException: Insert has filtered data, txn_id = 4013, tracking sql = select tracking_log from information_schema.load_tracking_logs where job_id=15375
        at com.starrocks.load.InsertOverwriteJobRunner.executeInsert(InsertOverwriteJobRunner.java:370)
        at com.starrocks.load.InsertOverwriteJobRunner.doLoad(InsertOverwriteJobRunner.java:170)
        at com.starrocks.load.InsertOverwriteJobRunner.handle(InsertOverwriteJobRunner.java:150)
        at com.starrocks.load.InsertOverwriteJobRunner.transferTo(InsertOverwriteJobRunner.java:213)
        at com.starrocks.load.InsertOverwriteJobRunner.prepare(InsertOverwriteJobRunner.java:257)
        at com.starrocks.load.InsertOverwriteJobRunner.handle(InsertOverwriteJobRunner.java:147)
        at com.starrocks.load.InsertOverwriteJobRunner.run(InsertOverwriteJobRunner.java:135)
        at com.starrocks.load.InsertOverwriteJobMgr.executeJob(InsertOverwriteJobMgr.java:90)
        at com.starrocks.qe.StmtExecutor.handleInsertOverwrite(StmtExecutor.java:2292)
        at com.starrocks.qe.StmtExecutor.handleDMLStmt(StmtExecutor.java:2385)
        at com.starrocks.qe.StmtExecutor.handleDMLStmtWithProfile(StmtExecutor.java:2301)
        at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.refreshMaterializedView(PartitionBasedMvRefreshProcessor.java:1144)
        at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doRefreshMaterializedView(PartitionBasedMvRefreshProcessor.java:485)
        at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doRefreshMaterializedViewWithRetry(PartitionBasedMvRefreshProcessor.java:391)
        at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doMvRefresh(PartitionBasedMvRefreshProcessor.java:343)
        at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.processTaskRun(PartitionBasedMvRefreshProcessor.java:196)
        at com.starrocks.scheduler.TaskRun.executeTaskRun(TaskRun.java:318)
        at com.starrocks.scheduler.TaskRunExecutor.lambda$executeTaskRun$0(CompletableFuture.java:1768)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:840)
     PROGRESS: 0%
EXTRA_MESSAGE: {"forceRefresh":false,"mvPartitionsToRefresh":["p20251110_20251117"],"refBasePartitionsToRefreshMap":{"test_base_table":["p20251110","p20251111","p20251105","p20251103","p20251115"]},"basePartitionsToRefreshMap":{},"processStartTime":1764161356081,"executeOption":{"priority":80,"taskRunProperties":{"warehouse":"default_warehouse","FORCE":"false","mvId":"15229"},"isMergeRedundant":false,"isManual":true,"isSync":false,"isReplay":false},"planBuilderMessage":{"test_base_table":"p20251110,p20251111,p20251105,p20251103,p20251115"}}
   PROPERTIES: {"warehouse":"default_warehouse","FORCE":"false","mvId":"15229"}
```

Additionally, when checking `information_schema.load_tracking_logs`, the error shows:

```
Error: The row is out of partition ranges. Please add a new partition.. Row: [1, 2025-11-03 10:00:00, 2025-11-03 00:00:00]
```

## Test Results Comparison

### StarRocks 3.4.9 (Working)

The same exact test case with the same data produces:

```
STATE: SUCCESS
ERROR_CODE: 0
ERROR_MESSAGE: NULL
PROGRESS: 100%
```

All week partitions refresh successfully.

### StarRocks 3.5.6 (Broken)

```
STATE: FAILED
ERROR_CODE: -1
ERROR_MESSAGE: Insert has filtered data
```

The refresh fails during INSERT OVERWRITE operation.

## Workaround

Switching to daily partitioning works correctly in all versions:

```sql
CREATE MATERIALIZED VIEW test_week_mv
PARTITION BY date_trunc('day', dt)
DISTRIBUTED BY HASH(id) BUCKETS 10
REFRESH ASYNC
AS
SELECT
    id,
    dt,
    date_trunc('week', dt) AS week_start
FROM test_base_table;
```

## Additional Context

- This issue only affects week partitioning; day and month partitioning work correctly
- The same test case works perfectly in 3.4.9 but fails starting from 3.5.0
- The existing test `test_mv_refresh_with_date_trunc_week` expects week partitioning to work without errors

## StarRocks Version

```sql
StarRocks 3.5.0 > select current_version();
+-------------------+
| current_version() |
+-------------------+
| 3.5.0-10d7323     |
+-------------------+
```

Also reproduced in:
- 3.5.6

## Environment

- Deployment: starrocks-allin1 Docker image
- OS: Linux

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[BUG] Week-Partitioned Materialized Views Fail to Refresh in 3.5.0+ #65983

Bug Description

Affected Versions

Steps to Reproduce

1. CREATE TABLE

2. INSERT INTO

3. CREATE MATERIALIZED VIEW

4. REFRESH MATERIALIZED VIEW

5. SELECT to check status

Expected Behavior

Real Behavior

Test Results Comparison

StarRocks 3.4.9 (Working)

StarRocks 3.5.6 (Broken)

Workaround

Additional Context

StarRocks Version

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] Week-Partitioned Materialized Views Fail to Refresh in 3.5.0+ #65983

Description

Bug Description

Affected Versions

Steps to Reproduce

1. CREATE TABLE

2. INSERT INTO

3. CREATE MATERIALIZED VIEW

4. REFRESH MATERIALIZED VIEW

5. SELECT to check status

Expected Behavior

Real Behavior

Test Results Comparison

StarRocks 3.4.9 (Working)

StarRocks 3.5.6 (Broken)

Workaround

Additional Context

StarRocks Version

Environment

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions