> ## Documentation Index
> Fetch the complete documentation index at: https://docs.paradime.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshoot Paradime State

> Fix common Paradime State problems: no summary at the end of a run, models that rebuild every time, models that miss new data, and schedules that build nothing.

Use this page when a run doesn't skip, clone, or build what you expected. In the Code IDE, `paradime-state explain --node <model>` shows the reason behind any node's decision: see [Explain a run in the Code IDE](/guides/paradime-state/read-a-run#explain-a-run-in-the-code-ide).

### No Paradime State summary at the end of the run

The run didn't go through Paradime State, so it ran as plain dbt™.

<Check>
  **Solution**

  Check each of these:

  * The environment runs dbt™ `2.0-latest`. The Code IDE always uses the workspace's version.
  * `PARADIME_STATE_ENABLED` is set in a box the run reads: Default or the run's Bolt environment for Bolt schedules, and Default or your own Code IDE box for the Code IDE. `PARADIME_STATE_DISABLED` isn't set in any of them.
  * Bolt has parsed your schedules since you set the variable. In Bolt, select **Parse schedules**.
  * In the Code IDE, you opened a new terminal after setting the variable.
  * The command is `dbt run` or `dbt build`. Other commands always run as plain dbt™.
  * The run isn't a DinoAI background agent session. Those always run plain dbt™.

  See [Turn on Paradime State](/guides/paradime-state/turn-on-paradime-state).
</Check>

### Every node builds on every run

The summary appears, but nothing is ever skipped.

<Check>
  **Solution**

  * **It's the first run in this schema.** The first run has nothing to compare with. The second run is the first that can skip.
  * **A notice says `no warehouse probe for adapter`.** Your warehouse isn't [supported](/guides/paradime-state/index#supported-warehouses), so runs build as plain dbt™.
  * **A notice says `proceeding without state optimization`.** Paradime State couldn't use its service during this run. The next run tries again. In the Code IDE, see [The Code IDE stopped skipping after a day](#the-code-ide-stopped-skipping-after-a-day).
  * **Something upstream builds every run.** Everything downstream of a node that builds also builds. Find the node that builds every run (often an incremental model) and see the next section.
</Check>

### A model rebuilds on every run

<Check>
  **Solution**

  * **It's an incremental model, a Python model, or uses a custom materialization.** These always build. This is expected.
  * **It uses `select *` directly on a `ref()` or `source()`.** List the columns, or select from a CTE.
  * **Its rendered SQL changes on every run**, because of a `var()`, an `env_var()`, `run_started_at`, or a macro whose output varies (for example, one that lists relations in a different order each time). Turn on [`compare_unrendered_code`](/guides/paradime-state/configuration-reference#compare_unrendered_code).
  * **It has `evaluate_volatile_sql: true`** and uses `current_timestamp`, `now()`, or `random()`. Turn the setting off if the model doesn't need the runtime value. See [`evaluate_volatile_sql`](/guides/paradime-state/configuration-reference#evaluate_volatile_sql).
  * **One of its tests failed in the last run.** A model whose test failed rebuilds on the next run. Fix the failing test.
  * **Paradime State can't parse its SQL.** SQL that can't be parsed, such as some warehouse-specific syntax, always builds. `paradime-state explain --node <model>` shows when this is the reason.
</Check>

### A model stays stale after new data lands

<Check>
  **Solution**

  * **The new data is within the model's `lag_tolerance`.** The default is 45 minutes. A model rebuilds once its upstream data has changed more than `lag_tolerance` after the version it was last built from, so a single small change can wait until the upstream changes again. For models that must pick up every change, set `lag_tolerance: 0s`. See [How `lag_tolerance` works](/guides/paradime-state/configuration-reference#how-lag_tolerance-works).
  * **The model has `require_fresh_data_from: all`**, and not every upstream has new data yet.
  * **The source's metadata doesn't change when data lands.** This is the case for views, external tables, and every source on DuckDB and MotherDuck. Declare a [`loaded_at_field`](/guides/paradime-state/configuration-reference#source-freshness).
  * **The model filters on `current_date`.** With `evaluate_volatile_sql` off, it can be reused on a later day. Turn on [`evaluate_volatile_sql`](/guides/paradime-state/configuration-reference#evaluate_volatile_sql).
</Check>

### The Code IDE stopped skipping after a day

Your Code IDE's access to Paradime State lasts 24 hours from when your IDE profile was last written. After that, runs build normally, with a notice that says `rejected this run as UNAUTHENTICATED`.

<Check>
  **Solution**

  Rewrite your IDE profile by changing a Code IDE variable. In **Settings** > **Environment Variables**, open `PARADIME_STATE_ENABLED`, change your **Code IDE** value (for example from `1` to `true`, which also turns it on), and save. Then open a new terminal.

  Saving without changing the value doesn't rewrite the profile. The notice also suggests setting a workspace variable, which you don't need to do.
</Check>

### Schedules that select with `state:` methods build nothing

Selectors that compare against a previous run's manifest, such as `state:modified+` and `state:new`, need that manifest when dbt™ selects nodes. With Paradime State on, selection runs without it, so these selectors don't select what you expect, and the run can finish without building anything.

<Check>
  **Solution**

  Keep Paradime State off for schedules that use `state:` selectors, typically Turbo CI and continuous deployment. Override `PARADIME_STATE_ENABLED` to `0` on those schedules. See [Turn it on or off for one schedule](/guides/paradime-state/turn-on-paradime-state#turn-it-on-or-off-for-one-schedule).
</Check>

### `dbt build --full-refresh` fails

The run fails with `unexpected argument '--full-refresh' found` when the build includes snapshots or tests.

<Check>
  **Solution**

  Use `dbt run --full-refresh` for incremental models, or turn Paradime State off for that run with `PARADIME_STATE_DISABLED`. See [Force a rebuild](/guides/paradime-state/configuration-reference#force-a-rebuild).
</Check>

### A hook or grants change has no effect

Pre-hooks and post-hooks don't run for a node that's skipped, and a change to `grants` or a hook on its own doesn't count as a change.

<Check>
  **Solution**

  [Force a rebuild](/guides/paradime-state/configuration-reference#force-a-rebuild) of the node to apply the change.
</Check>

### Two runs overlap

Paradime State doesn't lock runs. When two runs build the same nodes at the same time, the later one may build more than it needs to, and a notice says `another run had already advanced`.

<Check>
  **Solution**

  Schedule runs so that they don't build the same nodes at the same time, as you would without Paradime State.
</Check>


## Related topics

- [Paradime State](/guides/paradime-state/index.md)
- [Paradime State configuration reference](/guides/paradime-state/configuration-reference.md)
- [Read a Paradime State run](/guides/paradime-state/read-a-run.md)
- [Turn on Paradime State](/guides/paradime-state/turn-on-paradime-state.md)
- [Paradime State: build only what changed](/changelog/2026-09-28/paradime-state.md)