no result for dbt sync {sync_job_id} yet — check `cube dbt s

Error message

no result for dbt sync {sync_job_id} yet — check `cube dbt status {deployment} {}`

What it means

Raised by `cube dbt result <deployment> <sync_job_id>` when no result document is available for the sync job. A running sync, a `200 null` response, and an empty `{}` object all normalize to "not available yet" via available_result(). This is a state error, not a transport failure — the CLI points the user at `cube dbt status ... --wait` to learn when the result will exist.

Source

Thrown at rust/cube-cli/src/commands/dbt.rs:463

            let query: Query = Vec::new();
            let path = format!("{}/{sync_job_id}", base(deployment));
            match api.get_optional(&path, &query).await? {
                Some(status) => print_status(ctx.json, &status),
                None => bail!(
                    "no dbt sync {sync_job_id} on deployment {deployment} \
                     (it may not be visible yet, belong to another deployment, or have aged out)"
                ),
            }
        }
        Cmd::Result {
            deployment,
            sync_job_id,
        } => {
            let path = format!("{}/{sync_job_id}/result", base(deployment));
            match available_result(api.get_optional(&path, &Vec::new()).await?) {
                Some(result) => print_result(ctx.json, &result),
                // A running sync, `200 null`, and `{}` all mean "not available yet".
                None => bail!(
                    "no result for dbt sync {sync_job_id} yet — check \
                     `cube dbt status {deployment} {}`",
                    util::shell_quote(&sync_job_id)
                ),
            }
        }
        Cmd::Cancel {
            deployment,
            sync_job_id,
        } => {
            let res = api
                .delete(&format!("{}/{sync_job_id}", base(deployment)), None)
                .await?;
            if ctx.json {
                output::print_json(&res);
            } else {
                output::success(&format!("Cancelled dbt sync {sync_job_id}"));
            }

View on GitHub (pinned to 7d981676b3)

Solutions

Run `cube dbt status <deployment> <sync_job_id> --wait` first and call `dbt result` only after status is COMPLETED.
If the status is FAILED, there will never be a result — fix the sync failure instead.
Add a short retry/poll around the result call if you must fetch immediately after completion.
Verify the sync_job_id is for a finished job on the right deployment.

Example fix

// before: result fetched unconditionally
cube dbt sync 42
SYNC_ID=<id> cube dbt result 42 $SYNC_ID   # fails while sync still runs
// after: gate on status --wait
cube dbt sync 42 --branch x --wait && cube dbt result 42 <id>

Defensive patterns

Strategy: retry

Validate before calling

// Only fetch the result after the sync is terminal
let status = wait_for_status_terminal(...).await?;
if status_of(&status, "status") != "COMPLETED" {
    anyhow::bail!("sync not completed; result unavailable");
}

Try / catch

match result {
    Err(e) if e.to_string().contains("no result for dbt sync") => {
        // poll `cube dbt status --wait` then retry the result fetch
    }
    other => other?,
}

Prevention

Gate `dbt result` on `dbt status --wait` reporting COMPLETED.
Remember a FAILED sync never yields a result — check status first.
Allow a short poll window after COMPLETED; result writing lags slightly.
In scripts, chain commands: `dbt sync --wait && dbt result`.

When it happens

Trigger: `cube dbt result <deployment> <sync_job_id>` where the GET .../<sync_job_id>/result returns None, null, or {} — i.e. the sync is still RUNNING/PENDING, or just reached COMPLETED but the result document has not been written yet.

Common situations: Calling `dbt result` right after `dbt sync` without waiting for completion; a CI script that polls result instead of status; querying a result the instant the sync finished while the worker is still closing out the run.

Related errors

AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/a956595999f69f5c. Report an issue: GitHub.