sink won't be updated after an upstream materialized view is swaped

[tsekityam]

What do I have

I have a dbt risingwave project with the following models

-- mv_A
{{
    config(
        materialized="materialized_view",
        zero_downtime={'enabled': true},
    )
}}

select *, 'EEE' as dummy_column
from {{ ref('xxxx') }}

-- mv_B
{{
    config(
        materialized="materialized_view",
        zero_downtime={'enabled': true},
    )
}}

select dummy_column
from {{ ref('mv_A') }}

-- tbl_C
{{
  config(
    materialized = 'table_with_connector',
    )
}}

CREATE TABLE {{ this }} (
    dummy_column string  primary key
) ON CONFLICT DO UPDATE IF NOT NULL

-- sink_D
{{ config(materialized="sink") }}

CREATE SINK {{ this }}
into {{ ref('tbl_C') }} FROM {{ ref('mv_B') }};

I deploy the pipeline with dbt run, and everything works as expected

What do I do

I want to change the value of dummy column from EEE to FFF. So I updated the config of mv_A, and use dbt run --vars 'zero_downtime: true' to update the view by swap.

What do I see

mv_A and ``mv_Bare updated correctly, and the value of my dummy column is nowFFF`. But the dummy column in my `tbl_C` is still `EEE`, which is not updated.

I check the definition SQL of the tbl_C, and it is "definition":"CREATE SINK "dev"."dbt"."sink_D" INTO "dev"."dbt_vip"."tbl_C" FROM "dev"."dbt"."mv_B_dbt_zero_down_tmp_20251023T165835_277545+0000"" Look like we don't update the source of the table.

What do I expect

I want the definition of tbl_C is also updated to use the new mv_B, not the one being swapped out.

[chenzl25]

Hey @tsekityam https://github.com/risingwavelabs/dbt-risingwave/blob/main/ZERO_DOWNTIME_MV_README.md#downstream-sink-handling it is a known limitation of ZERO DOWNTIME MV.

Downstream Sink Handling
⚠️ Critical Limitation: Zero downtime rebuilds do not automatically handle downstream Sinks that depend on the materialized view.

When a materialized view has downstream Sinks:

Manual Intervention Required: You must manually recreate or update Sinks after the MV rebuild
Pipeline Disruption: The data pipeline may be temporarily disrupted until Sinks are updated
Sink Dependencies: Sinks will continue to reference the old MV definition until manually updated
Example Scenario:

-- Original MV
CREATE MATERIALIZED VIEW user_stats AS SELECT id, name FROM users;

-- Downstream Sink
CREATE SINK user_sink FROM user_stats WITH (...);

-- After zero downtime rebuild with new column:
-- MV now has: SELECT id, name, email FROM users;
-- But Sink still references old schema - manual update required
Recommended Approach for Sinks:

Plan MV updates during maintenance windows when Sink disruption is acceptable
Update Sinks immediately after MV rebuild
Consider using traditional rebuild methods for MVs with critical downstream Sinks