Hello @mnissen1337  !

Have you though about decoupling view DDL from the continuously running streaming job ?

Do not make the view creation a downstream task of the stream because continuous jobs are not meant to reach success and in DBKS  continuous trigger jobs cannot use normal task dependencies.

Instead you can manage the view as deployment time, idempotent DDL. In other words you can create the target delta table explicitly or run a small bootstrap job once to create it, then deploy CREATE OR REPLACE VIEW ... separately before starting or restarting the stream. In prod, I would avoid relying on streaming schema inference as the contract for a downstream view and define the table schema deliberately and allow controlled schema evolution only when needed.

If you want a more declarative DBKS native model, think about lakeflow declarative pipelines or streaming tables and materialized views where streaming tables and derived SQL objects are managed together as pipeline assets. (