cube-js/cube · error

no dbt sync {sync_job_id} on deployment {deployment}. It may

Error message

no dbt sync {sync_job_id} on deployment {deployment}. It may belong to another deployment, have aged out, or this tenant may not serve the dbt-sync endpoints yet

What it means

The Cube CLI's `dbt sync --wait` / `dbt status --wait` polls the deployment's dbt-sync status endpoint for a given sync_job_id. When the endpoint returns 404 continuously for longer than MISSING_GRACE (a short grace window that tolerates a sync not being visible yet), wait_for_sync gives up and bails. It means the CLI cannot see the sync job at all — not that the sync failed.

Source

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

    api: &Client,
    deployment: i64,
    sync_job_id: &str,
    timeout: Duration,
    interval: Duration,
) -> Result<Value> {
    let path = format!("{}/{}", base(deployment), sync_job_id);
    // A Cell, not a plain variable: the poll closure hands back a future that
    // borrows what it captures, and a mutable capture would make each call borrow
    // the closure itself — which the borrow checker rejects even though the calls
    // are strictly sequential.
    let missing_since = std::cell::Cell::new(None::<Instant>);

    wait::poll(Wait::new("dbt sync", timeout, interval), || async {
        let Some(status) = api.get_optional(&path, &Vec::new()).await? else {
            let since = missing_since.get().unwrap_or_else(Instant::now);
            missing_since.set(Some(since));
            if since.elapsed() > MISSING_GRACE {
                bail!(
                    "no dbt sync {sync_job_id} on deployment {deployment}. It may belong \
                     to another deployment, have aged out, or this tenant may not serve \
                     the dbt-sync endpoints yet"
                );
            }

            return Ok(Progress::Waiting("starting".to_string()));
        };
        missing_since.set(None);

        let state = util::status_of(&status, "status");
        if state == COMPLETED || state == FAILED {
            return Ok(Progress::Done(status));
        }

        Ok(Progress::Waiting(status_label(&status)))
    })
    .await

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Verify the sync_job_id belongs to this deployment: re-run `cube dbt sync <deployment>` and use the syncJobId it prints.
  2. Confirm the deployment number is correct — list deployments and check you are polling the one that started the sync.
  3. If the sync is old, check whether it aged out of retention and start a fresh sync instead.
  4. Check with Cube support/admin whether this tenant serves the dbt-sync endpoints; if not, upgrade or use a tenant that does.
  5. If the sync was just started, retry — a slow-to-register job is tolerated only briefly by the grace window.

Example fix

// before: polling a stale ID captured from an old CI run
let sync_job_id = env::var("SYNC_JOB_ID")?; // may be from another deployment
// after: start the sync and capture the ID in the same run
let started = api.post(&base(deployment), Some(&body)).await?;
let sync_job_id = output::field(&started, "syncJobId");
Defensive patterns

Strategy: retry

Validate before calling

// Confirm the job exists on the right deployment before --wait
let status = api.get_optional(&format!("{base}/{sync_job_id}"), &query).await?;
if status.is_none() {
    anyhow::bail!("sync {sync_job_id} not found on {deployment}; re-run `cube dbt sync` to mint a fresh ID");
}

Try / catch

match result {
    Err(e) if e.to_string().contains("no dbt sync") => {
        // start a new sync and capture its syncJobId before waiting
    }
    other => other?,
}

Prevention

When it happens

Trigger: Running `cube dbt sync <deployment> --wait` or `cube dbt status <deployment> <sync_job_id> --wait` where GET /build/api/v1/deployments/<deployment>/dbt-sync/<sync_job_id> (approximately) returns None/404 on every poll until the grace period elapses: the sync_job_id was created on a different deployment, retention has aged it out, or the tenant's API does not implement dbt-sync endpoints.

Common situations: Typing a sync job ID from another deployment's output; referencing a sync older than the retention window; pointing the CLI at a Cube Cloud tenant/region that predates the dbt-sync feature; a typo'd ID or wrong deployment number in a CI script.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


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