Skip to main content
Use this page for errors tied to connections, warehouse metadata, or local workspace state.

​
PARA-1000: Missing production warehouse connection

This error appears when you run a production dbt job in Bolt without an active production warehouse connection. It also appears when your production run references a target that does not exist.
Solution
  • Add an active production connection for the scheduler.
  • Confirm the connection works before rerunning.
  • If you use a custom target, confirm that target exists.
See Setting Up Data Warehouse Connections and Scheduler environment.

​
PARA-1007: Couldn’t fetch info-schema from Snowflake for production catalog

Paradime could not fetch the information schema for your production catalog. Common causes include:
  • The production user does not exist.
  • The stored credentials are invalid.
  • The Snowflake account no longer exists or has expired.
SolutionCheck the production connection details.Test the connection again.If the test fails, confirm the credentials with your Snowflake admin.See Snowflake.

​
PARA-1007: Couldn’t fetch info-schema from Snowflake for dev catalog

Paradime could not fetch the information schema for your development catalog. Common causes include:
  • The development user does not exist.
  • The stored credentials are invalid.
  • The Snowflake account no longer exists or has expired.
SolutionCheck the development connection details.Test the connection again.If the test fails, confirm the credentials with your Snowflake admin.See Snowflake.

​
250001 (08001): Multi-factor authentication is required for this account

The connection signs in to Snowflake with a username and password, and Snowflake requires multi-factor authentication (MFA) for that user. Paradime signs in with no one there to approve an MFA prompt, so Snowflake rejects every attempt. Snowflake now requires a second factor for every human user who signs in with a password, and blocks password sign-in for service users. See Snowflake’s MFA rollout. Any Snowflake connection that still uses a password can fail this way: Code IDE, Bolt, Agent, or Radar.
SolutionSwitch the connection to key-pair authentication. Snowflake doesn’t ask for MFA when you sign in with a key pair.
  1. Generate a key pair for the Snowflake user on the connection. Follow Snowflake’s guide to generating an encrypted or unencrypted key pair.
  2. Set the public key on that user:
  3. Open Workspace Settings > Environments and edit the connection. Set Auth Method to Key Pair, then enter the username, the private key (including the BEGIN and END lines), and the passphrase if you set one.
In the Code IDE you can also use Snowflake OAuth, so each developer signs in through Snowflake instead of saving a password in Paradime.See Key-pair authentication, and Snowflake cost connection for Radar.

​
250001 (08001): Authentication attempt rejected by the current authentication policy

An authentication policy on your Snowflake account, or on the connection’s user, doesn’t allow the way the connection signs in. For example, the policy allows key pair only, and the connection still signs in with a password.
SolutionAsk your Snowflake admin which sign-in methods the policy allows (its AUTHENTICATION_METHODS). Then do one of these:
  • Switch the connection to key-pair authentication, using the steps in the previous error, and confirm the policy allows KEYPAIR.
  • Have your admin allow the sign-in method the connection uses, for that user.
See Authentication policies in the Snowflake documentation.

​
Radar: Schema ‘SNOWFLAKE.ACCOUNT_USAGE’ does not exist or not authorized

The Snowflake cost connection saves, but no cost data shows in Radar, and the Radar cost sync fails with this error. The Radar connection form has no role field, so Paradime uses the default role of the connection’s Snowflake user. Here that default role isn’t paradime_cost_role, so Snowflake runs the Radar queries as PUBLIC, which can’t read SNOWFLAKE.ACCOUNT_USAGE. This happens when:
  • The user already existed, so create user if not exists didn’t set its default role.
  • The user’s default role is set, but the role isn’t granted to the user.
SolutionRun as a user admin:
Then run desc user paradime_cost_user; and confirm that DEFAULT_ROLE is PARADIME_COST_ROLE. Replace paradime_cost_user with your user name if you use a different user.See Snowflake cost connection.

​
BigQuery: The job encountered an internal error during execution

On dbt™ v2, the same error reads:
BigQuery accepted the model’s query job, then failed it with an internal error on its side (BigQuery reason jobInternalError). See BigQuery’s error messages.
Solution
  1. Run the schedule again. BigQuery’s guidance for this error is to retry the job.
  2. If the same models fail in every run, open one of the failed jobs in the BigQuery console and run the same SQL there. On dbt™ v2, the error links to the job.
  3. If the SQL also fails in the console, the problem is on the BigQuery side, not in dbt™ or Paradime. Check whether the tables the query reads changed recently, and contact Google Cloud support with the job IDs.

​
BigQuery: The job encountered an error during execution

On dbt™ v2, the error includes the BigQuery reason jobBackendError. BigQuery accepted the model’s query job, then failed it with an internal error on its side.
SolutionRun the schedule again. If the same models fail with this error, or with the internal error in the previous entry, in every run, follow the steps in the previous entry.

​
PARA-1014: Couldn’t list databases when running paradime sources generate

Paradime could not list databases to generate sources.yml. This usually means your development connection does not have enough access to query information schema.
SolutionReview the permissions on your development connection.Then check the setup guide for your warehouse in Code IDE environment.

​
PARA-1015: Clear Paradime local storage

Some UI issues come from stale local browser data. For the full reset steps, see Clear Paradime local storage.