dbt-labs/dbt-core · info

[/\\]

Error message

[/\\]

What it means

A panic from `Regex::new(r"[/\\]").expect("valid regex")` — the compile-time-constant `PATH_UNSAFE_REGEX` used to rewrite path separators in test-name segments that become filenames under `target/generic_tests/`. Like the sibling `CLEAN_REGEX`, the pattern is a hardcoded, syntactically valid literal, so the expect should never fail in normal operation; it only fires if the regex engine fails to compile a known-good pattern.

Source

Thrown at crates/dbt-parser/src/resolve/resolve_tests/persist_generic_data_tests.rs:1140

            })?
        }
        _ => dbt_yaml::Value::Mapping(dbt_yaml::Mapping::new(), Span::default()),
    };

    Ok(merge_yaml_values(passed_in_cfg, embedded_cfg))
}

static CLEAN_REGEX: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"[^0-9a-zA-Z_]+").expect("valid regex"));

/// Narrow sanitizer for the test-name segments that become a filename
/// (`source_name` / `resource_name`). The synthesized name is used directly
/// as `target/generic_tests/<name>.sql`, so only path separators must be
/// rewritten — anything else is left alone to avoid changing test names /
/// `unique_id`s for inputs that already worked (e.g. `prod.events`,
/// `my-source`).
static PATH_UNSAFE_REGEX: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"[/\\]").expect("valid regex"));

/// Generates a unique hash for a generic test based on uncleaned kwargs.
/// This matches mantle's behavior where the unique_id includes a hash of the
/// test metadata (namespace, name, kwargs) WITHOUT cleaning, ensuring that
/// tests with different expressions (e.g., '> 0' vs '= 0') get different
/// unique_ids even if their cleaned names would be identical.
///
/// https://github.com/dbt-labs/dbt-core/blob/2ef17b836e39d1b4c7a55f14b448a2254378302e/core/dbt/parser/schema_generic_tests.py#L104-L117
fn generate_test_unique_id_hash(
    fqn_name: &str,
    test_macro_name: &str,
    namespace: Option<&String>,
    kwargs: &BTreeMap<String, Value>,
) -> String {
    const HASH_LENGTH: usize = 10;

    // Mantle builds test_metadata as:
    //   metadata = {"namespace": builder.namespace, "name": builder.name, "kwargs": builder.args}

View on GitHub (pinned to 0267ce9170)

Solutions

1. If the constant was modified, restore the valid pattern `[/\\]` (in Rust source: `r"[/\\]"` matches `/` and `\`)
2. Rebuild and run tests covering generic-test filename sanitization to catch static regex errors early
3. If it reproduces with the stock pattern, check the regex crate version for regressions and pin/upgrade accordingly

Example fix

// before (edited, invalid)
static PATH_UNSAFE_REGEX: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"[/").expect("valid regex"));

// after
static PATH_UNSAFE_REGEX: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"[/\\]").expect("valid regex"));

// wrap parser invocation; this panic is not user-recoverable, but catch at a boundary
let result = std::panic::catch_unwind(|| run_parse(...));
if result.is_err() {
    eprintln!("parser panicked compiling internal regex; check regex crate build/version");
}

When it happens

Trigger: Practically never from user data — the pattern is static and only matches `/` or `\`. It can trigger on first use of `PATH_UNSAFE_REGEX` if the regex runtime fails to compile the literal, e.g. an edited/invalid constant, a broken regex crate build, or a runtime fault during lazy initialization.

Common situations: A developer edits the constant and introduces invalid regex syntax (e.g. an unescaped lone backslash); a patched or misbuilt regex dependency; extreme environments where lazy static initialization fails.

Related errors

• valid regex
• [^0-9a-zA-Z_]+
• valid regex
• valid regex
• Schema not found for canonical FQN: {}

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