What causes "valid regex" in dbt-labs/dbt-core?

Fix the regex literal syntax that fails to compile (check parentheses, lookahead syntax)

valid regex

Error message

valid regex

What it means

`is_table_ddl` (crates/dbt-adapter/src/metadata/snowflake/mod.rs:315) compiles a static `fancy_regex` pattern once and calls `.expect("valid regex")`. Because the pattern is a hardcoded literal, the panic is unreachable unless the source regex was edited and no longer compiles — it is a compile-time-style invariant guard.

Source

Thrown at crates/dbt-adapter/src/metadata/snowflake/mod.rs:315

                last_altered,
                (table_type = 'VIEW' OR table_type = 'MATERIALIZED VIEW') AS is_view
             FROM {}.INFORMATION_SCHEMA.TABLES
             WHERE {}",
        database,
        where_clauses.join(" OR ")
    ))
}

fn is_table_ddl(ddl: &str) -> bool {
    static TABLE_REGEX: Lazy<fancy_regex::Regex> = Lazy::new(|| {
        fancy_regex::Regex::new(
            r"(?ix)
                ^\s*create\b
                (?:\s+(?!table\b)\w+)*
                \s+table\b
                ",
        )
        .expect("valid regex")
    });

    if ddl.trim().is_empty() {
        return false;
    }
    // `is_match` returns Result because fancy-regex's backtracking engine
    // can fail on pathological inputs; treat any engine error as "not a
    // table" so a malformed DDL doesn't get cached as a view by mistake.
    TABLE_REGEX.is_match(ddl).unwrap_or(false)
}

/// Render the anonymous block (the body that goes inside `EXECUTE IMMEDIATE $$...$$`)
/// that calls `GET_DDL` over a list of FQNs and captures per-object errors as
/// part of the result set.
///
/// The caller is responsible for wrapping the returned string in
/// `EXECUTE IMMEDIATE $$ ... $$`. The rendered block accepts no parameters
/// and returns a result set with columns (fqn, view_definition, error).

View on GitHub (pinned to 0267ce9170)

Solutions

Fix the regex literal syntax that fails to compile (check parentheses, lookahead syntax)
Add a unit test that compiles the pattern so regressions are caught in CI instead of at runtime
Pin/upgrade fancy-regex if a version change altered accepted syntax

Example fix

// before
.expect("valid regex")
// after
.unwrap_or_else(|e| panic!("invalid DDL regex literal: {e}")) // plus a #[test] that builds it

Defensive patterns

Strategy: validation

Validate before calling

// compile-time guard in tests
#[test]
fn ddl_regex_compiles() {
    fancy_regex::Regex::new(r"(?ix)^\s*create\b(?:\s+(?!table\b)\w+)*\s+table\b").unwrap();
}

Prevention

Add unit tests compiling all static regex literals
Validate regex edits with the fancy-regex crate docs
Keep regex literals simple; prefer split patterns over exotic syntax
Pin fancy-regex version in Cargo.lock

When it happens

Trigger: Only when the embedded regex literal in the source is modified into an invalid pattern (unbalanced groups, bad syntax for fancy-regex's backtracking engine).

Common situations: Contributors editing the DDL-detection regex with a syntax error; fancy-regex version changes that reject previously-accepted syntax (rare).

Related errors

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/ce4eb143e9e3af93. Report an issue: GitHub.