Skip to main content
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.

​
No Paradime State summary at the end of the run

The run didn’t go through Paradime State, so it ran as plain dbt™.
SolutionCheck 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.

​
Every node builds on every run

The summary appears, but nothing is ever skipped.
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, 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.
  • 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.

​
A model rebuilds on every run

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.
  • 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.
  • 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.

​
A model stays stale after new data lands

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.
  • 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.
  • The model filters on current_date. With evaluate_volatile_sql off, it can be reused on a later day. Turn on evaluate_volatile_sql.

​
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.
SolutionRewrite 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.

​
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.
SolutionKeep 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.

​
dbt build --full-refresh fails

The run fails with unexpected argument '--full-refresh' found when the build includes snapshots or tests.
SolutionUse dbt run --full-refresh for incremental models, or turn Paradime State off for that run with PARADIME_STATE_DISABLED. See Force a rebuild.

​
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.
SolutionForce a rebuild of the node to apply the change.

​
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.
SolutionSchedule runs so that they don’t build the same nodes at the same time, as you would without Paradime State.