windmill-labs/windmill · error

Error getting type name: {}

Error message

Error getting type name: {}

What it means

In the same Java parser allowlist dispatch, the `Err(e)` arm fires when `typ_node.utf8_text(code.as_bytes())` itself fails — i.e. the tree-sitter node's byte range cannot be extracted from the source (invalid UTF-8 or a malformed node range). The parser bails with 'Error getting type name: {e}' instead of a type-name problem.

Source

Thrown at backend/parsers/windmill-parser-java/src/lib.rs:112

fn find_typ<'a>(typ_node: Node<'a>, code: &str) -> anyhow::Result<(Typ, Option<Value>)> {
    let null = Some(serde_json::Value::Null);
    let res = match typ_node.kind() {
        #[rustfmt::skip]
        "type_identifier" => {
            match typ_node.utf8_text(code.as_bytes()) {
                Ok("String")      => (Typ::Str(None), null),
                Ok("Byte")        => (Typ::Bytes, null),
                Ok("Short")       => (Typ::Int, null),
                Ok("Integer")     => (Typ::Int, null),
                Ok("Long")        => (Typ::Int, null),
                Ok("Float")       => (Typ::Float, null),
                Ok("Double")      => (Typ::Float, null),
                Ok("Boolean")     => (Typ::Bool, null),
                Ok("Character")   => (Typ::Str(None), null),
                Ok("Object")      => (Typ::Object(ObjectType::new(None, Some(vec![]))),null), // TODO: Complete the object type
                Ok(s)       => bail!("Unknown type `{s}`"),
                Err(e) => bail!("Error getting type name: {}", e),
            }
        }
        #[rustfmt::skip]
        "integral_type" => {
            match typ_node.utf8_text(code.as_bytes()) {
                Ok("byte")   => (Typ::Bytes, None),
                Ok("short")  => (Typ::Int, None),
                Ok("int")    => (Typ::Int, None),
                Ok("long")   => (Typ::Int, None),
                Ok("char")   => (Typ::Str(None), None),
                Ok(s)  => bail!("Unknown type `{s}`"),
                Err(e) => bail!("Error getting type name: {}", e),
            }
        }
        "floating_point_type" => {
            match typ_node.utf8_text(code.as_bytes()) {
                Ok("float") => (Typ::Float, None),
                Ok("double") => (Typ::Float, None),

View on GitHub (pinned to e474e8803c)

Solutions

  1. Re-save the Java script file as UTF-8 (without BOM) and re-upload/re-sync.
  2. Strip non-ASCII characters from type declarations in the script.
  3. Update the tree-sitter-java grammar / windmill-parser-java crate so node ranges match the current grammar version.
  4. If persisting scripts through tooling, ensure the pipeline reads/writes files as UTF-8 strings, not raw bytes.

Example fix

// before
$ iconv -f windows-1252 MyScript.java > fixed.java  # still not UTF-8-safe in places
// after
$ iconv -f windows-1252 -t UTF-8 MyScript.java > fixed.java
Defensive patterns

Strategy: validation

Validate before calling

# ensure the Java source is valid UTF-8 before upload
file MyScript.java
datamash check 2>/dev/null || true
iconv -f UTF-8 -t UTF-8 MyScript.java > /dev/null || { echo "not valid UTF-8"; exit 1; }

Type guard

function isValidUtf8(bytes: Uint8Array): boolean {
  try { new TextDecoder("utf-8", { fatal: true }).decode(bytes); return true; }
  catch { return false; }
}

Prevention

When it happens

Trigger: Calling find_typ on a Java type node whose source bytes are not valid UTF-8 (e.g. a Java file with non-UTF-8 encoding containing exotic characters in/around a type), or a corrupted/inconsistent tree-sitter parse where the node range exceeds the input.

Common situations: Java sources saved with windows-1252/latin-1 encoding; files with BOM or binary content sneaking into script storage; parser version drift producing nodes outside the source buffer.

Related errors


AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/702687ef49143ead. Report an issue: GitHub.