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)))
})
.awaitView on GitHub (pinned to 7d981676b3)
Solutions
- Verify the sync_job_id belongs to this deployment: re-run `cube dbt sync <deployment>` and use the syncJobId it prints.
- Confirm the deployment number is correct — list deployments and check you are polling the one that started the sync.
- If the sync is old, check whether it aged out of retention and start a fresh sync instead.
- Check with Cube support/admin whether this tenant serves the dbt-sync endpoints; if not, upgrade or use a tenant that does.
- 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
- Always take sync_job_id from the same run's `dbt sync` output, never from memory or another environment's logs.
- Pair `--wait` with the sync invocation itself (`dbt sync --wait`) instead of waiting on a previously recorded ID.
- Confirm the deployment number in scripts via a variable set at deploy time.
- Don't poll sync jobs older than your tenant's retention window.
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
- no dbt sync {sync_job_id} on deployment {deployment} (it may
- no result for dbt sync {sync_job_id} yet — check `cube dbt s
- dbt sync {sync_job_id} failed: {}
- branch {branch} is not building ({verdict}){}. {}
- nothing is building branch {branch} (status {status}{}). If
AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02).
Data as JSON: /api/errors/0eea1399b73ceb82.
Report an issue: GitHub.