@Rocky with version ≥ 4.0.8 will Starrocks follow a table rename in routine loads and/or async materialized views?

In StarRocks version 4.0.8 (and generally from v3.1 onwards), the behavior for table renames regarding Routine Loads and Async Materialized Views is as follows: 1. Asynchronous Materialized Views (MVs) * Does it follow? Yes, but with a status change. * Behavior: Async Materialized Views reference their base tables by Internal ID rather than name. This means the lineage and metadata are preserved even if the base table is renamed. * State Transition: When a base table is renamed (or swapped), the dependent Materialized View is automatically set to

Inactive

to prevent potential metadata mismatches or inconsistent rewrites during the transition. * Recovery: StarRocks features Automatic Activation (controlled by the FE config

enable_mv_automatic_active_check

, which is

true

by default in recent versions). The system will periodically attempt to activate inactive MVs. Furthermore, StarRocks will attempt to activate the MV automatically before the next scheduled or manual refresh. 2. Routine Loads * Does it follow? No. * Behavior: Routine Load jobs are bound to the table name specified at the time of creation. If you rename the target table, the Routine Load job will continue to look for the original name. * Result: Because the old table name no longer exists, the Routine Load tasks will eventually fail or the job will enter a

PAUSED

state after reaching the error threshold, reporting that the target table cannot be found. * Recommendation: If you rename a table that is a target for Routine Load, you must STOP the existing job and CREATE a new Routine Load job pointing to the new table name. You can use

SHOW CREATE ROUTINE LOAD

to get the original configuration (offsets, etc.) before stopping it. Summary Table Feature | Follows Rename? | Internal Mechanism | State After Rename Async MV | Yes | References by ID | Becomes `Inactive`; auto-activates later. Routine Load | No | References by Name | Job will fail/pause (table not found). Tip for v4.0.8+: If you are performing frequent table swaps or renames for ETL, it is recommended to use Materialized Views to abstract the downstream queries, as they are more resilient to underlying name changes than loading jobs. References • release_notes/release-4.0.md • release_notes/release-3.3.md