@Rocky

Preprocess mv mv1 failed for query tables:[mv2, mv3, mv4, mv5, mv6]
 java.lang.NullPointerException: Cannot invoke "com.starrocks.catalog.MvBaseTableUpdateInfo.getToRefreshPartitionNames()" because "mvBaseTableUpdateInfo" is null

mv2-mv6 are async materialized views based on external iceberg catalog. How can I rectify?

This error indicates a NullPointerException (NPE) in the StarRocks Frontend (FE) during the planning/preprocessing phase of the materialized view (

mv1

) refresh. Specifically, StarRocks is trying to calculate which partitions of the base tables (

mv2

through

mv6

) have changed, but it encountered a null metadata object (

mvBaseTableUpdateInfo

) for one of them. Since `mv2`–`mv6` are asynchronous materialized views based on an external Iceberg catalog, here are the steps to identify and rectify the issue: 1. Check for Inactive Materialized Views If any of the base MVs (`mv2`–`mv6`) become inactive (e.g., due to a schema change in the underlying Iceberg table or a failed refresh), the refresh for the dependent MV (

mv1

) will fail. * Action: Run

SHOW MATERIALIZED VIEWS

and check the

is_active

column for

mv2

through

mv6

. * Fix: If any are

false

, activate them manually:

sql
    ALTER MATERIALIZED VIEW mv2 ACTIVE;
    -- Repeat for others if necessary

2. Ensure Base MVs Have Been Refreshed Nested MVs require the base MVs to have at least one successful refresh "version" recorded in the metadata. If a base MV was recently created and never refreshed, or if its last refresh task failed,

mv1

may fail to resolve the partition dependencies. * Action: Check the refresh history of the base MVs:

sql
    SELECT * FROM information_schema.task_runs
    WHERE task_name LIKE 'mv2%' -- replace with mv names
    ORDER BY create_time DESC LIMIT 10;

* Fix: Manually trigger a refresh for the base MVs starting from the bottom of the dependency chain:

sql
    REFRESH MATERIALIZED VIEW mv2;
    -- Wait for completion, then refresh others, finally mv1

3. Inspect Metadata Consistency Use the

inspect_mv_refresh_info

function to see if the metadata for the MVs is readable. If this function throws an error or returns an empty set unexpectedly, it confirms a metadata inconsistency. * Action:

sql
    SELECT inspect_mv_refresh_info('mv1');
    SELECT inspect_mv_refresh_info('mv2'); -- check each base MV

4. Verify Iceberg Partition Alignment If

mv1

is a partitioned MV and its partitions are mapped to the partitions of `mv2`–`mv6`, ensure that the partitioning columns in the Iceberg tables haven't been modified (e.g., partition evolution in Iceberg) in a way that breaks the StarRocks mapping. * Starting from v3.1.4, StarRocks supports partition-level change detection for Iceberg. Ensure your StarRocks version is up to date (ideally v3.2.x or v3.3.x) as there were several bug fixes related to

MvBaseTableUpdateInfo

and nested MVs in these versions. 5. Workaround: Force a Full Refresh If the NPE is caused by a bug in the incremental partition tracking logic, you can try to bypass the preprocessing by forcing a full refresh of the MV, which may re-initialize the metadata. * Fix:

sql
    REFRESH MATERIALIZED VIEW mv1 WITH FORCE;

Summary of Possible Causes * Version Bug: This specific NPE in

MvBaseTableUpdateInfo

is often addressed in patch releases. If you are on an early 3.1 or 3.2 version, consider upgrading to the latest maintenance release. * External Metadata Stale: StarRocks's cache of the Iceberg catalog metadata might be out of sync. Try

REFRESH EXTERNAL TABLE <iceberg_table_name>

for the base tables. References • using_starrocks/async_mv/use_cases/data_lake_query_acceleration_with_materialized_views.md • sql-reference/sql-statements/materialized_view/CREATE_MATERIALIZED_VIEW.md • using_starrocks/async_mv/Materialized_view.md