Summary

When two or more recursive LOCAL views become dead during optimization, compilation fails with:

Operators nested_176 {
    0 operators...
} and nested_177 {
    0 operators...
} have the same persistent id e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

e3b0c442...b855 is the SHA-256 of the empty string. Both operators are recursive circuits that have no operators.

Seen in a user program on v0.381.0. It also reproduces on a main build from 2026-11-10 (89fc01f).

Minimal repro

CREATE TABLE t(src BIGINT, dst BIGINT);

DECLARE RECURSIVE VIEW p1(src BIGINT, dst BIGINT);
CREATE LOCAL VIEW p1 AS SELECT src, dst FROM t UNION SELECT p1.src, t.dst FROM p1 JOIN t ON t.src = p1.dst;

DECLARE RECURSIVE VIEW p2(src BIGINT, dst BIGINT);
CREATE LOCAL VIEW p2 AS SELECT src, dst FROM t UNION SELECT p2.src, t.dst FROM p2 JOIN t ON t.src = p2.dst;

-- Always empty
CREATE LOCAL VIEW empty_left AS
SELECT CAST(NULL AS BIGINT) AS id FROM (VALUES (1)) AS one(x) WHERE FALSE;

CREATE MATERIALIZED VIEW o AS
SELECT l.id, r.dst FROM empty_left AS l LEFT JOIN p1 AS r ON l.id = r.src
UNION ALL
SELECT l.id, r.dst FROM empty_left AS l LEFT JOIN p2 AS r ON l.id = r.src
UNION ALL
SELECT src, dst FROM t;

Compiled with the pipeline-manager flags (-i -je --alltables --ignoreOrder --crates <name> --enterprise).

An even smaller program gives the same error: two recursive LOCAL views that no view reads, plus any materialized view.

Cause

In the user program, 9 of 12 recursive LOCAL views went dead this way. Each one was read only through a LEFT JOIN whose left side was a ... FROM (VALUES (1)) WHERE FALSE view.

Possible fix

FindDeadCode already keeps a nested operator when one of its outputs is reachable (FindDeadCode.java:112). RemoveOperators could drop a DBSPNestedOperator that is not in keep. As a guard, CheckPersistentIds could reject a nested operator with no operators.

Workaround

Declare the recursive views with CREATE VIEW instead of CREATE LOCAL VIEW. This fixed the user program.