windmill-labs/windmill · warning

{e:#}

Error message

{e:#}

What it means

In Windmill's DuckDB materialization flow, `record_mat` persists the materialization outcome (partition row, status, row count) via `record_materialization`. This error is the `{e:#}` re-wrap of any failure from that best-effort write. The job itself is not failed by it, but the partition/materialization record is lost, degrading the asset grid view.

Source

Thrown at backend/windmill-worker/src/duckdb_executor.rs:1241

        error: error.map(|e| e.to_string()),
        schema: schema.clone(),
    };
    let res: anyhow::Result<()> = match conn {
        Connection::Sql(db) => {
            let partition_res = windmill_common::materialization::record_materialization(
                db,
                w_id,
                req.asset_kind,
                &req.asset_path,
                &req.partition,
                req.status,
                req.snapshot_id,
                req.row_count,
                req.job_id,
                req.error.as_deref(),
            )
            .await
            .map_err(|e| anyhow::anyhow!("{e:#}"));
            // Schema capture is a separate, independently best-effort write (its
            // own transaction for the per-asset advisory lock); a failure here
            // must not lose the partition row above.
            if let Some(cols) = schema.as_ref() {
                if let Err(e) = record_asset_schema_best_effort(
                    db,
                    w_id,
                    meta.asset_kind,
                    &meta.asset_path,
                    cols,
                    snapshot_id,
                    job_id,
                )
                .await
                {
                    tracing::warn!("failed to record captured asset schema: {e:#}");
                }
            }

View on GitHub (pinned to e474e8803c)

Solutions

1. Check backend/worker logs for the underlying `{e:#}` chain root cause (usually a Postgres connection or constraint error).
2. Verify the Windmill database is reachable and migrations are up to date (`windmill_migration` table at latest revision).
3. Re-run the materialization job — the record write is best-effort and idempotent per partition, so a retry repopulates the grid row.
4. If it's a constraint/permission error, inspect the asset path and partition values for invalid characters or an asset that was deleted concurrently.

Example fix

// before: failure silently lost in generic re-wrap
.map_err(|e| anyhow::anyhow!("{e:#}"))
// after: log and still keep the run from failing, but with context
.map_err(|e| {
    log::warn!("record_materialization failed for {}/{}: {e:#}", meta.asset_path, meta.partition);
    anyhow::anyhow!("materialization record failed: {e:#}")
})

// check DB reachability before launching materializations
psql "$DATABASE_URL" -c 'select 1' || echo 'DB down: materialization records will be lost'

// best-effort: log, don't fail the job
match record_materialization(...).await {
    Ok(()) => {},
    Err(e) => log::warn!("materialization record lost: {e:#}"),
}

When it happens

Trigger: Calling `record_materialization` (direct SQL path, `Connection::Sql`) when the insert/upsert into the materialization tables fails — DB unreachable, constraint violation on the (asset_kind, asset_path, partition) key, permission/schema issue, or serialization failure.

Common situations: Postgres restart or transient network drop mid-materialization; stale schema after a Windmill upgrade where migrations haven't run; duplicate partition rows racing a concurrent materialization of the same asset; agent worker posting to an API that returns 5xx.

Related errors

• Unsupported database type:${dbType}
• Unsupported database type
• Unsupported database type
• Column ${column.field} is not nullable and has no default va
• Table name is required

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