Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Snowflake Syncs and Troubleshooting

A configured Snowflake source has Status, Data, and Settings tabs. Connection tests and data reads use the same stored key, Snowflake service user, and static Galdera egress IP, so a successful test checks the same route used by a sync.

For initial prerequisites and the generated Snowflake script, see Connecting to Snowflake.

Run and monitor a sync

Snowflake syncs are manual today. Open the source's Status tab and click Sync now whenever you want fresh data. Scheduled sync controls are marked Coming soon and do not run unattended.

A sync reads the configured history window through the source's date column, stages the result in the workspace's tenant-isolated landing storage, and then processes it into Galdera. Galdera records each run in the source history. Only one run can be active for a source at a time; you can cancel an active run from its status line.

An unchanged sync does not duplicate existing data. New rows extend the current data contract. If columns were added or removed, the source changes to Needs review: open Data, check the column roles and frequency, then click Confirm mapping. A failed run remains in the run history with its reason and can be retried.

Test the connection

Use the magnifying-glass Test connection action on the source status line whenever you need to verify the connection. Before a table has been selected, the test checks that Galdera can sign in and see schemas. After setup, it also checks that the selected table or view can be read.

The result is stored with the connection and remains visible after a reload. A failed test can change the source status when the problem affects the whole connection, such as a rejected key or blocked network policy.

Resolve common Snowflake errors

Your Snowflake network policy is blocking Galdera

Add the exact Galdera /32 address shown in the setup script or error message to the allowlist that applies to GALDERA_SVC (or the Snowflake user you entered when connecting). Preserve the policy's existing entries. Tests, browsing, previews, and syncs all use this same address.

Snowflake rejected our key or Needs re-auth

For a new connection, confirm that the generated setup script ran in the correct Snowflake account and set the key on GALDERA_SVC, or on the Snowflake user you entered. For a connection that worked previously, rotate its key from Settings → Credentials. A credential in Needs re-auth cannot be reused by a new source until it is repaired.

No schemas are visible or the selected database is not visible

The sign-in worked, but GALDERA_READER cannot see a data schema in that database. Re-run the database and schema grants from the setup script. Confirm that the database name belongs to the connected Snowflake account.

The table is missing or not shared with us

Snowflake can report the same error for a misspelled object and a missing grant. Check the schema, table or view name, including capitalization, then re-run the relevant USAGE and SELECT grants. Future grants cover newly created objects only when the generated grant statements were kept, and not in schemas that have their own future grants. See Schemas with their own future grants in Connecting to Snowflake.

The selected date column is missing, ambiguous, or has the wrong type

Choose the date column from Galdera's picker and make sure it is a Snowflake DATE or TIMESTAMP column. Rename or cast it in a view if the source column has another type.

This sync found no rows

The connection worked, but no rows matched the displayed date window. Return to the setup fields, choose an earlier custom start date, and run the first sync again. For an existing source, also confirm that the date column contains values in the configured range.

The connector is temporarily unavailable or the test timed out

This usually means Galdera could not start or reach its connector runtime, or Snowflake did not answer in time. Retry after a short wait. If it continues, contact Galdera support with the source name and the time of the attempt; do not send private keys or credentials.

Rotate the Snowflake key

Key rotation applies to every source that reuses the same Snowflake account credential.

  1. Open any affected Snowflake source and go to Settings → Credentials.
  2. Click Rotate key.
  3. Copy the generated script and run it in Snowflake as SECURITYADMIN. It installs the new public key in Snowflake's second key slot, so the current key continues to work during the change.
  4. Return to Galdera and click I've run it — switch to the new key.
  5. After Galdera confirms the new key is in use, you can remove the old key using the statement included in the generated script.

Do not remove the old Snowflake key before Galdera confirms the switch.

Disconnect / revoke access

Disconnecting a source in Galdera deletes the stored key once no other source uses it, but leaves the Snowflake objects in place. To revoke Galdera's access in Snowflake, run these statements:

USE ROLE SECURITYADMIN;
DROP USER GALDERA_SVC;
DROP ROLE GALDERA_READER;
USE ROLE SYSADMIN;
DROP WAREHOUSE GALDERA_XS_WH;

Dropping GALDERA_SVC stops every Galdera source on that Snowflake account at once.

If you connected with a Snowflake user your team created, replace DROP USER GALDERA_SVC with whatever your process requires: drop that user, or remove Galdera's key with ALTER USER <your user> UNSET RSA_PUBLIC_KEY.