materialized_view: ALTER branch never issues REFRESH — intentional?

[sd-db]

The materialized_view materialization at dbt-adapters/src/dbt/include/global_project/macros/materializations/models/materialized_view.sql branches four ways: CREATE, REPLACE (full refresh), REFRESH (no diff), ALTER (diff with on_configuration_change='apply', requires_full_refresh=False).

CREATE / REPLACE / REFRESH all materialize data. ALTER does not — and every adapter follows that pattern:

Adapter	Non-full-refresh ALTER emits
dbt-postgres	update indexes
dbt-redshift	autorefresh toggle
dbt-bigquery	alter ... set <options>
dbt-databricks	alter ... set tags / schedule

None append REFRESH MATERIALIZED VIEW.

Symptom

A dbt run that changes only metadata-class config (tag, schedule) leaves MV data stale for that run. The next run with no further drift refreshes correctly, so the staleness is bounded to one cycle — but it contradicts how a user would read the docs at https://docs.getdbt.com/reference/resource-configs/materialized?version=1.11#creation-precedence:

when there are no configuration changes detected, perform the default action for the type — e.g. apply refresh for a materialized view.

Reasonable reading: refresh runs on every `dbt run`. Actual behavior: refresh runs only when no config drift is detected.

Ask

Is this intentional? Two options:

1. Yes → docs should clarify: REFRESH fires only on no-diff runs; non-full-refresh ALTER paths are metadata-only.
2. No → one-line fix per adapter: append the dispatched `refresh_materialized_view(target_relation)` call after the non-full-refresh branch in each `get_alter_materialized_view_as_sql`.

Context

Surfaced from databricks/dbt-databricks#1419 / databricks/dbt-databricks#1424. That fix removed a separate bug that always took the ALTER path; the residual one-cycle staleness on intentional tag/schedule changes is what motivates this question.