This message was deleted.
# replication-ask-ai
s
This message was deleted.
k
Based on the knowledge sources, here are some things to try for your ingress timeout issue: Troubleshooting "Timed out waiting for ingress" 1. Upgrade abctl first Your output shows you're running an outdated version of abctl. The message indicates an upgrade is available (
v0.29.0 → v0.30.4
). Upgrading is highly recommended before trying anything else:
Copy code
# Using curl
curl -LsfS https://get.airbyte.com | bash -

# Or using Homebrew
brew upgrade abctl
Then verify:
abctl version
[Upgrading abctl] 2. Try a fresh install after upgrading After upgrading abctl, do a clean reinstall:
Copy code
abctl local uninstall --persisted
rm -rf ~/.airbyte/abctl
abctl local install
[abctl reference] 3. Known root causes for ingress timeouts According to a GitHub issue tracking abctl reliability problems, there are a few known causes: [abctl reliability issue] â€ĸ Resource constraints: No preflight checks exist for CPU/memory/disk. If your VM is under-resourced, pods take longer to start and the ingress verification times out (hardcoded at 1 minute). â€ĸ Network/proxy issues: If you're behind a corporate proxy, image pulls can fail silently, causing later Helm timeouts. You may need to exec into the
airbyte-abctl-control-plane
container and configure proxy settings. â€ĸ Image pull failures: Docker Hub rate limiting can cause silent failures that manifest as ingress timeouts. 4. If you're behind a proxy
Copy code
docker exec -it airbyte-abctl-control-plane bash
# Then test connectivity:
curl https://ifconfig.io
If that fails, you'll need to configure proxy settings inside the container. [nginx install issue] 5. Pin to a known-good chart version Some users have had success pinning to chart version 1.7.2:
Copy code
abctl local install --chart-version=1.7.2
[Helm chart issue] Important note: The ingress timeout is a known reliability issue with abctl on cloud VMs and constrained environments. Upgrading abctl to the latest version (
v0.30.4
) is the most important first step, as several ingress-related fixes were included in recent releases. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai when I ran
docker exec -it airbyte-abctl-control-plane bash
it went to
root
( root@airbyte-abctl-control-plane:/#), then I got an IP address (xx.xx.xxx.xxx) when running
curl <https://ifconfig.io>
k
Good news — the fact that
curl https://ifconfig.io
returned an IP address means your container has internet connectivity. So a proxy/network block is not the cause of your issue. Based on the knowledge sources, here are the next steps to diagnose further: 1. Check pod status inside the container While still inside
airbyte-abctl-control-plane
, run:
Copy code
kubectl get pods -A
Look for any pods in
ImagePullBackOff
,
ErrImagePull
,
CrashLoopBackOff
, or
Pending
state — these are common causes of ingress timeouts that don't get surfaced clearly. [abctl reliability issue] 2. Check logs of any failing pods
Copy code
kubectl logs <pod_name> -n <namespace>
Or using the kubeconfig from outside the container:
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods
[abctl FAQ] 3. Upgrade abctl to v0.30.4 Your previous error output showed that
v0.30.4
is available and highly recommended. This is still the most important step, as newer versions include improved diagnostics and reliability fixes. [abctl reliability issue] 4. Check your system resources The knowledge sources note that insufficient resources are a common silent cause of timeouts — with no preflight checks currently in place. Minimum recommended specs are: â€ĸ At least 4 CPUs (8 recommended) â€ĸ At least 8 GB RAM (16 recommended) â€ĸ At least 20 GB disk If your machine is constrained, try:
Copy code
abctl local install --low-resource-mode
[abctl install issue] Could you share the output of
kubectl get pods -A
from inside the container? That would help narrow down the exact cause. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai Here is the result for kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE airbyte-abctl airbyte-abctl-airbyte-bootloader 0/1 Completed 0 38m airbyte-abctl airbyte-abctl-cron-766c44cf47-w9wws 1/1 Running 0 38m airbyte-abctl airbyte-abctl-server-6f668f5cb4-fsnj8 1/1 Running 0 38m airbyte-abctl airbyte-abctl-temporal-7d6495ccf6-shbkg 1/1 Running 0 38m airbyte-abctl airbyte-abctl-worker-747857b5b9-kdsw2 1/1 Running 0 38m airbyte-abctl airbyte-abctl-workload-api-server-7f5df8589f-b66mf 1/1 Running 0 38m airbyte-abctl airbyte-abctl-workload-launcher-5cbfdbcf5-bqnz7 1/1 Running 1 (37m ago) 38m airbyte-abctl airbyte-db-0 1/1 Running 0 38m ingress-nginx ingress-nginx-controller-6597574fdc-9kznp 1/1 Running 0 37m kube-system coredns-668d6bf9bc-2kfqx 1/1 Running 0 43m kube-system coredns-668d6bf9bc-5rcb5 1/1 Running 0 43m kube-system etcd-airbyte-abctl-control-plane 1/1 Running 0 44m kube-system kindnet-wgmdr 1/1 Running 0 43m kube-system kube-apiserver-airbyte-abctl-control-plane 1/1 Running 0 44m kube-system kube-controller-manager-airbyte-abctl-control-plane 1/1 Running 0 44m kube-system kube-proxy-sd8gh 1/1 Running 0 43m kube-system kube-scheduler-airbyte-abctl-control-plane 1/1 Running 0 44m local-path-storage local-path-provisioner-7dc846544d-cptzv 1/1 Running 0 43m
k
This is actually great news! Looking at your pod output: â€ĸ All pods are
Running
✅ â€ĸ The bootloader is
Completed
✅ (this is expected — it's a one-time init job) â€ĸ The ingress-nginx controller is
Running
✅ Your Airbyte installation appears to be healthy. The
ERROR: Timed out waiting for ingress
you saw earlier was likely a false failure — the ingress controller just took longer than the hardcoded 1-minute timeout to become responsive, even though it eventually came up fine. This is a known issue with
abctl
. [abctl reliability issue] Try accessing Airbyte now Open your browser and navigate to:
Copy code
http://localhost:8000
Or if you're on a remote VM, use the server's IP address on port 8000. If the UI doesn't load Run this from outside the container to check the ingress:
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl get ingress
Going forward Since your cluster is healthy, upgrading
abctl
to
v0.30.4
before your next install/upgrade is still strongly recommended, as it includes reliability improvements that may prevent this false timeout from occurring again. [abctl reliability issue] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai here is the result for
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE ingress-abctl nginx ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com,localhost,host.docker.internal 10.xx.xxx.xxx 80 41m
k
Your ingress looks correctly configured! It shows: â€ĸ Hosts: your EC2 hostname,
localhost
, and
host.docker.internal
✅ â€ĸ Address:
10.xx.xxx.xxx
(internal IP assigned) ✅ â€ĸ Port:
80
✅ Try accessing Airbyte Since you're on an EC2 instance, try opening in your browser:
Copy code
http://ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com:8000
If it still doesn't load, check two things: 1. Verify the EC2 Security Group allows inbound traffic on port 8000 In your AWS Console, go to your EC2 instance → Security Groups → Inbound Rules and make sure port
8000
is open to your IP (or
0.0.0.0/0
for testing). [EC2 with abctl] 2. Confirm abctl was installed with the correct
--host
flag
By default,
abctl
only configures ingress for
localhost
. For EC2 access, it needs to be installed with your EC2 hostname explicitly: [EC2 with abctl]
Copy code
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
The
--insecure-cookies
flag is needed if you're running over plain HTTP rather than HTTPS. Since your ingress already shows the EC2 hostname as a host, it looks like you may have already done this — so the Security Group rule on port 8000 is the most likely remaining issue. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai I've upgraded
abctl
, please give me more detail for EC2 Security Group allows inbound traffic on port 8000
k
The knowledge sources mention that you need to ensure your EC2 Security Group allows inbound traffic on port 8000, but don't provide detailed step-by-step AWS Console instructions. However, based on what the Airbyte docs do state: [EC2 with abctl] > Ensure the security group configured for the EC2 Instance allows traffic in on the port (8000 by default) that you deploy Airbyte on. For the detailed steps on how to configure this in AWS, you'll need to refer to the AWS Security Groups documentation directly, as the knowledge sources don't contain the step-by-step AWS Console instructions. What you need to configure (in summary) In your AWS Console: 1. Go to EC2 → Instances → select your instance 2. Click the Security tab → click your Security Group 3. Click Edit inbound rules 4. Add a rule: â—Ļ Type: Custom TCP â—Ļ Port range:
8000
â—Ļ Source: Your IP address (e.g.
My IP
) for security, or
0.0.0.0/0
for open access (not recommended for production) 1. Click Save rules Security note Airbyte strongly recommends securing your instance with TLS rather than running over plain HTTP, as plain HTTP exposes your password in clear text. [EC2 with abctl] If you must run over HTTP, make sure you used the
--insecure-cookies
flag:
Copy code
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai Airbyte worked before I configured this inbound rules on ec2
k
That's a useful clue! If Airbyte was working before you added the inbound rules, the issue is likely not the Security Group itself. Looking back at the conversation, the more likely culprits are: 1. The --host flag and --insecure-cookies Since you're accessing over HTTP on EC2, you need both flags when installing: [EC2 with abctl]
Copy code
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
2. The ingress timeout was a false failure As we identified earlier, all your pods were healthy (`Running`/`Completed`). The
ERROR: Timed out waiting for ingress
was likely a false negative due to the hardcoded 1-minute timeout in
abctl
on slower cloud VMs — not an actual installation failure. [abctl reliability issue] What I'd suggest Try reinstalling now that you've upgraded
abctl
to `v0.30.4`:
Copy code
abctl local uninstall
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
Then access Airbyte at:
Copy code
http://ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com:8000
I'm sorry I can't pinpoint exactly what changed when you configured the inbound rules, as the knowledge sources don't contain enough detail to explain that specific interaction. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai Airbyte is deployed on instance type t3.xlarge
k
A
t3.xlarge
gives you 4 vCPUs and 16 GB RAM, which is a reasonable instance size for running Airbyte. How it compares to recommendations Based on the knowledge sources: â€ĸ CPU: 4 CPUs meets the minimum recommended spec of "4 or more CPUs" ✅ [OSS Quickstart] â€ĸ RAM: 16 GB meets the recommended 8 GB minimum ✅ [OSS Quickstart] â€ĸ Disk: Make sure you have at least 30 GB allocated, as connector images (~300 MB each) and logs can add up quickly [Scaling Airbyte] Things to watch on a t3.xlarge â€ĸ Memory during syncs: The source worker reads up to 10,000 records in memory. For tables with large row sizes this can be significant. Monitor memory usage during syncs. [Scaling Airbyte] â€ĸ No need for
--low-resource-mode
: That flag is intended for 2 CPU / 8 GB environments. Your instance is capable enough to run in normal mode. [OSS Quickstart] â€ĸ Concurrent syncs: Make sure your instance can schedule up to
2 x <number of concurrent connections>
pods at once. [Scaling Airbyte] Overall, a
t3.xlarge
should be sufficient for testing and moderate production workloads with Airbyte. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai should I run
rm -rf ~/.airbyte/
k
Be cautious — this depends on your situation. What rm -rf ~/.airbyte/ does It removes everything in the
~/.airbyte/
directory, including: â€ĸ The kubeconfig (
~/.airbyte/abctl/abctl.kubeconfig
) â€ĸ The cluster data â€ĸ All Airbyte data (connections, sources, destinations, configurations) This is more aggressive than the recommended cleanup command. [abctl reference] The recommended approach is:
Copy code
abctl local uninstall --persisted
rm -rf ~/.airbyte/abctl
Note it only removes
~/.airbyte/abctl
, not the entire
~/.airbyte/
directory. [abctl reference] My recommendation for your situation You don't need to do this yet. Looking back at our conversation: â€ĸ All your pods are healthy ✅ â€ĸ Ingress is configured correctly ✅ â€ĸ The timeout error was likely a false failure ✅ Instead, try first:
Copy code
abctl local uninstall
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
Only do a full wipe with
rm -rf ~/.airbyte/abctl
if the reinstall fails and you're comfortable losing all your existing Airbyte configuration. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai good news, everything is set up🎉
k
That's fantastic news! 🎉 Glad we got it working! To summarize what resolved your deployment: â€ĸ ✅ Upgraded
abctl
to the latest version (
v0.30.4
) â€ĸ ✅ Installed with the correct
--host
and
--insecure-cookies
flags for EC2 HTTP access â€ĸ ✅ EC2 Security Group configured for port
8000
Useful next steps â€ĸ Get your credentials to log in:abctl local credentials â€ĸ Check your installation status anytime:abctl local status â€ĸ Start moving data by setting up your first source, destination, and connection in the UI. [What's next] Keep in mind â€ĸ Airbyte recommends securing your instance with TLS/HTTPS rather than running over plain HTTP long-term, as HTTP exposes your password in clear text. [EC2 with abctl] â€ĸ Keep
abctl
updated — upgrading is as simple as re-running the install script:curl -LsfS https://get.airbyte.com | bash - Good luck with your data pipelines! 🚀 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai wanted to confirm, as I ran
rm -rf ~/.airbyte/
before, everything was wiped out, it will do full refresh to overwrite the old data in destination, right?
k
This is an important distinction to clarify —
rm -rf ~/.airbyte/
and a Full Refresh Overwrite are two completely separate things.
What rm -rf ~/.airbyte/ actually wiped This command only removed your Airbyte configuration (connections, sources, destinations, credentials, kubeconfig, etc.) from your local EC2 instance. It did not touch any data in your destination (e.g. BigQuery, Snowflake, Postgres, etc.). [Data deletion] > When you delete a connection in Airbyte, the data that has been synced to the destination will not be automatically deleted. The data that has already been synced will remain in the destination. What happens when you re-sync When you recreate your connections and run a new sync, the behavior depends on the sync mode you configure: â€ĸ Full Refresh | Overwrite: Will destroy all existing data in the destination table and replace it with fresh data from the source. [Full Refresh Overwrite] â€ĸ Full Refresh | Overwrite + Deduped: Same as above but deduplicates by primary key. [Full Refresh Overwrite Deduped] â€ĸ Incremental: Will append/update only new records on top of existing destination data. Bottom line â€ĸ Your destination data is safe —
rm -rf ~/.airbyte/
did not touch it ✅ â€ĸ Whether your next sync overwrites old destination data depends entirely on the sync mode you choose when recreating your connections, not on the
rm -rf
command itself. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai it seems airbyte is doing a full refresh for the first sync after I created the connection even though I configured Incremental sync mode
k
This is expected behavior in Airbyte — it is not a bug! Why the first sync is always a Full Refresh When you configure Incremental sync mode, the very first sync is equivalent to a Full Refresh because there is no prior state (cursor) to reference. Airbyte needs to establish a baseline by pulling all existing data first. [Incremental Append] > If the sync is running for the first time, it is equivalent to a Full Refresh since all data will be considered as new. This applies to all incremental sync modes: â€ĸ Incremental | Append [Incremental Append] â€ĸ Incremental | Append + Deduped [Incremental Append Deduped] What happens on subsequent syncs After the first sync establishes the cursor value, all subsequent syncs will only pull new or modified records since the last sync — which is the incremental behavior you configured. [Sync Modes] Summary So your setup is working correctly! 🎉 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai so this full refresh will overwrite the old data in the destination for the 1st sync
k
Not necessarily — it depends on the Incremental sync mode you configured: Incremental | Append The first full refresh will append all records to the destination table. It will not overwrite or delete any existing data. [Incremental Append] > Records in the warehouse destination will never be deleted or mutated. Incremental | Append + Deduped Similarly, the first sync will append all records, but will also deduplicate the final table by primary key. Existing data is not overwritten. [Sync Modes] Summary Bottom line Since you configured Incremental sync mode, your first sync will load all source data but will not overwrite or delete your existing destination data — it will only add to it. Your old data in the destination remains safe. [Incremental Append] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai so it will add new data and deduplicate the data
k
Yes, exactly! For Incremental | Append + Deduped, here is what happens: Each sync (including the 1st): 1. Append: New or modified records from the source are added to the raw/history table in the destination [Incremental Append Deduped] 2. Deduped: The final table is deduplicated by primary key, keeping only the most recent version of each record based on the cursor field (e.g.
updated_at
) [Incremental Append Deduped] > Deduped means that data in the final table will be unique per primary key. This is determined by sorting the data using the cursor field and keeping only the latest de-duplicated data row. What this means in practice So you get the best of both worlds: â€ĸ ✅ Full history preserved in the raw table â€ĸ ✅ Clean, deduplicated view in the final table â€ĸ ✅ No duplicate primary keys in the final table [Incremental Append Deduped] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai how long does the data sync normally take if it has 500k data? it's been 18 mins and it's still syncing
k
The knowledge sources do not contain a definitive answer for exactly how long a 500K record sync should take, as sync speed varies significantly depending on many factors. What the knowledge sources do show From real-world examples in the community: 18 minutes for 500K records This is not unusual — it could be completely normal depending on: â€ĸ Connector type (database JDBC connectors tend to be slower due to
fetchSize
batching) â€ĸ Record size (larger rows = slower throughput) â€ĸ Source/destination combination â€ĸ Your EC2 instance network latency to source and destination â€ĸ Whether this is the first sync (full load of all 500K records) What you can do right now Check the sync progress in the Airbyte UI logs to see the current records read count, or run: [Connection Timeline]
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl logs -f <source-pod-name>
Since this is likely your first sync (full load), I'd give it more time before worrying — 18 minutes for 500K records on a first sync is not alarming. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai I got this warning when running a data sync: Warning from destination: Cannot drop column '_AIRBYTE_EMITTED_AT' which belongs to a clustering key
k
This is a known issue in Airbyte! The warning occurs because Airbyte is trying to drop the
_AIRBYTE_EMITTED_AT
column (an older metadata field), but it cannot because it is being used as a clustering key in your destination table. [Forum Post] Why this happens
_AIRBYTE_EMITTED_AT
is a pre-Destinations V2 metadata field. Its equivalent in the current Destinations V2 is
_airbyte_extracted_at
. When Airbyte tries to migrate/update the schema, it cannot drop the old column because it belongs to a clustering key. [Airbyte Metadata Fields] How to fix it The fix depends on your destination: For Snowflake: Manually drop the clustering key on the affected table first: [Forum Post]
Copy code
ALTER TABLE <your_table> CLUSTER BY ();
Then drop the column:
Copy code
ALTER TABLE <your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
Then reset and re-sync the connection in Airbyte. For Redshift: Disable the sort key first: [Forum Post]
Copy code
ALTER TABLE <your_table> ALTER SORTKEY NONE;
Then retry the sync. Important notes â€ĸ âš ī¸ Back up your data before making any manual DDL changes to destination tables â€ĸ After making the changes, you may need to reset the connection in Airbyte and re-sync â€ĸ This is a known backward compatibility issue when upgrading connectors Could you share which destination you are using (Snowflake, Redshift, BigQuery, etc.)? That would help narrow down the exact fix for your case. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai I'm using snowflake
k
Since you're using Snowflake, here is the specific fix: Fix for Snowflake Step 1: Remove the clustering key on the affected table
Copy code
ALTER TABLE <your_schema>.<your_table> CLUSTER BY ();
Step 2: Drop the old column
Copy code
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
[Forum Post] Good news — this is being fixed in Airbyte A recent pull request (#82272) specifically addresses this by removing the column DROP logic during schema evolution in the Snowflake destination connector (version
4.0.47
onwards). This means: [Snowflake PR] > Airbyte will stop dropping columns during schema evolution in the Snowflake destination entirely. So after upgrading to the latest Snowflake destination connector, this warning should no longer appear. Steps to fully resolve right now 1. Run the SQL above on your affected Snowflake table(s) 2. Reset the connection in Airbyte UI 3. Re-sync the connection 4. Upgrade your Snowflake destination connector to
4.0.47
or later to prevent this from happening again âš ī¸ Make sure to back up your data before making any manual DDL changes to your Snowflake tables. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai it has 522k records loaded, I've manually started a data sync and they are queued
k
Looking at your screenshots, I can see a few important things: What the screenshots show Timeline (Screenshot 1): â€ĸ ✅ Previous sync loaded 522,451 records in 26m 57s before it was cancelled â€ĸ 🔄 New sync is currently running Logs (Screenshot 2): â€ĸ âš ī¸ The logs show repeated
Heartbeat not progressing
warnings, with time since last progress increasing every 10 seconds (
1123s → 1133s → 1143s → 1153s...
) â€ĸ This means the CDC heartbeat has not progressed for ~18+ minutes â€ĸ There is also a line showing:
Received offset commit request on 'LSN{1C04/340000F8}'
What this means The connector is stuck in a heartbeat not progressing state — similar to the issue described in GitHub issue #49803. The sync is running but not making progress. [Github Issue] What to do 1. Increase the initial CDC waiting time Since your dataset has 500K+ records, the connector may need more time. Set the initial wait time to a higher value (e.g. 600 seconds): [Postgres Troubleshooting] > If you know there are database changes to be synced, but the connector cannot read those changes, the root cause may be insufficient waiting time. 2. Check your replication slot Run this on your Postgres source to check if the replication slot is healthy:
Copy code
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn 
FROM pg_replication_slots;
3. Reset the connection If the heartbeat continues to not progress, try resetting the connection in the Airbyte UI and re-syncing. This clears the saved LSN offset and starts fresh. [Postgres Troubleshooting] The sync will eventually auto-close itself once the heartbeat timeout is reached, but resetting and re-syncing is the cleaner approach here. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai here is the result for replication slot
k
Looking at your replication slot results, here is what I can see: Replication Slot Status What this means âš ī¸ There is a problem here — the
confirmed_flush_lsn
(
1C04/340000F8
) is ahead of
restart_lsn
(
1C04/340000C0
). This matches exactly the issue described in the logs from your previous screenshot where the LSN commit was on
1C04/340000F8
. [Github Issue] This is the known bug where: > The
confirmed_flush_lsn
is advancing beyond the saved state LSN, causing the connector to get stuck. Recommended Fix 1. Check your Postgres source connector version The fix was released in version `3.7.2`: [Github Issue] > Airbyte released
3.7.2
which fixes this issue 2. If not on
3.7.2
, upgrade your source-postgres connector
in the Airbyte UI: â€ĸ Go to Sources → select your Postgres source â€ĸ Check the connector version and upgrade to
3.7.2
or later 3. As an immediate workaround, set up a heartbeat table to keep the LSN advancing: [Postgres Troubleshooting]
Copy code
CREATE TABLE airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);

ALTER PUBLICATION <publicationName> ADD TABLE airbyte_heartbeat;
Then configure the Debezium heartbeat query in your Postgres source settings:
Copy code
INSERT INTO airbyte_heartbeat (text) VALUES ('heartbeat')
4. Reset the connection in Airbyte UI and re-sync after upgrading the connector. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai the version is 3.8.4
k
You are on version 3.8.4, which is well past the
3.7.2
fix. So the connector version is not the issue here. What's likely causing the problem Looking back at your logs and replication slot results, the issue is the
confirmed_flush_lsn
advancing beyond the saved state LSN
— even on newer connector versions. There is an open PR (#79671) that addresses this specifically: [Fix CDC LSN] > CDC syncs will correctly advance the replication slot's
confirmed_flush_lsn
, preventing unbounded WAL growth on the source PostgreSQL database. This is especially important after initial snapshots where only the
lsn
field is present in the Debezium offset. Immediate steps to try 1. Set up a heartbeat table (most effective workaround right now): [Postgres Troubleshooting]
Copy code
CREATE TABLE airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);

ALTER PUBLICATION <publicationName> ADD TABLE airbyte_heartbeat;
Then in your Postgres source Advanced settings → Debezium heartbeat query:
Copy code
INSERT INTO airbyte_heartbeat (text) VALUES ('heartbeat')
2. Reset the connection in Airbyte UI: â€ĸ Go to Connections → select your connection â€ĸ Click Reset to clear the saved LSN state â€ĸ Then trigger a new sync 3. Change Invalid CDC position behavior to
Re-sync data
instead of
Fail sync
as a temporary measure to avoid hard failures while the LSN issue resolves itself. [Github Issue] The heartbeat table is the most reliable workaround until a full fix is released in a newer connector version. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai should i create
airbyte_heartbeat
table directly in the current schema?
k
Based on the knowledge sources, you can create the
airbyte_heartbeat
table in any schema you prefer — the documentation uses
public
schema as an example: [Postgres Troubleshooting] > You can put your heartbeat table anywhere. I just put mine in my public schema. Recommendation You have two options: Option 1: Create it in the
public
schema (simplest)
Copy code
CREATE TABLE public.airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);

ALTER PUBLICATION <publicationName> ADD TABLE public.airbyte_heartbeat;
Then set the heartbeat query to:
Copy code
INSERT INTO public.airbyte_heartbeat (text) VALUES ('heartbeat')
Option 2: Create it in your current schema
Copy code
CREATE TABLE <your_schema>.airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);

ALTER PUBLICATION <publicationName> ADD TABLE <your_schema>.airbyte_heartbeat;
Then set the heartbeat query to:
Copy code
INSERT INTO <your_schema>.airbyte_heartbeat (text) VALUES ('heartbeat')
Important notes â€ĸ ✅ The schema location doesn't matter as long as it's added to the publication â€ĸ ✅ You do not need to sync the heartbeat table in Airbyte — just adding it to the publication is enough â€ĸ ✅ Make sure your Airbyte Postgres user has write access to whichever schema you choose 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai but why it shows '184.62 MB|522,451 records loaded|26m 57s'
k
Looking back at your first screenshot, the cancelled sync showed
184.62 MB | 522,451 records loaded | 26m 57s
. Here is what that means: Why it shows those metrics even though it was cancelled The sync was manually cancelled by you (
Default User cancelled a sync
), but Airbyte still reports the data that was successfully loaded before the cancellation happened. [Connection Timeline] > Cancelled — Someone cancelled the sync before it finished. This means: â€ĸ ✅ 522,451 records were successfully loaded to Snowflake before you cancelled â€ĸ ✅ 184.62 MB of data was moved during those 26m 57s â€ĸ ❌ The sync did not fully complete — there may be more records remaining in the source that were not yet synced What the metrics represent [Connection Timeline] Bottom line The data that was loaded (522,451 records) is already in your Snowflake destination. When you run the next sync, since you are using Incremental | Append + Deduped, Airbyte will pick up from where it left off and sync the remaining records without duplicating what was already loaded. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai it means i don't need to run another data sync, it will re-sync after 6 hours
k
Not quite — there are a couple of things to consider here: 1. Your sync schedule matters It depends on what schedule you configured for your connection. If you set it to every 6 hours, then yes, Airbyte will automatically trigger the next sync after 6 hours. [Sync Schedules] > After that, a sync is run once the time since the last sync (whether it was triggered manually or due to a schedule) has exceeded the schedule interval. 2. The cancelled sync affects the timer Since the sync was cancelled, the 6-hour timer starts from the time of cancellation. So the next scheduled sync will run 6 hours after the cancellation, not after the original start time. [Sync Schedules] 3. The heartbeat issue is still unresolved âš ī¸ Looking back at your logs, the
Heartbeat not progressing
issue is still present. If you don't set up the heartbeat table fix first, the next scheduled sync may get stuck again in the same way. Recommendation Before waiting for the next scheduled sync: 1. Set up the heartbeat table as discussed 2. Reset the connection in Airbyte UI 3. Then either wait for the scheduled sync or manually trigger a new sync to confirm it works correctly This way you avoid the same heartbeat issue repeating on the next scheduled run. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai I checked the data in destination snowflake and the results in columns
airbyte_extracted_at
and
airbyte_cdc_updated_at
for the tables are the same when syncing data
k
The knowledge sources do not contain enough specific information to fully explain why
_airbyte_extracted_at
and
_ab_cdc_updated_at
would show the same values in your case. However, here is what the knowledge sources do tell us about these two fields: What each field means Why they could appear the same These two values can coincidentally match if: â€ĸ The records were inserted and synced at nearly the same time — i.e. Airbyte ran the sync very shortly after the database transaction occurred â€ĸ This is more likely on a first sync where all records are loaded at once What to check Run this query in Snowflake to see if they are truly identical or just appear similar:
Copy code
SELECT 
    _airbyte_extracted_at,
    _ab_cdc_updated_at,
    _airbyte_extracted_at = _ab_cdc_updated_at AS are_equal
FROM <your_schema>.<your_table>
LIMIT 100;
If they are consistently identical across all records, I'd recommend joining the Airbyte Community Slack or opening a support ticket with your connector versions and sync logs for a deeper investigation. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai let's see the status 6 hours after I cancelled the data sync with the incremental mode, this mode will append less data than the first sync
k
Yes, that is correct! Here is what to expect: Why the 2nd sync will append less data Since your first sync (even though cancelled) already loaded 522,451 records to Snowflake, Airbyte saved the cursor/state up to that point. The next incremental sync will only pull records that are new or modified since that last cursor value. [Incremental Append] > Incremental means syncing only replicates new or modified data. This prevents re-fetching data that you have already replicated from a source. What to expect after 6 hours One thing to watch out for âš ī¸ The heartbeat not progressing issue we identified earlier is still unresolved. Before the 6-hour scheduled sync triggers, make sure you have: 1. ✅ Created the
airbyte_heartbeat
table 2. ✅ Added it to your publication 3. ✅ Configured the Debezium heartbeat query in your Postgres source settings Otherwise the next sync may get stuck again in the same way regardless of how much data needs to be synced. [Postgres Troubleshooting] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai I checked the log and the issue is the 'airbyte_emitted_at', and how can i find the tables that have this column
k
Your screenshot confirms the exact error we discussed earlier: >
Cannot drop column '_AIRBYTE_EMITTED_AT' which belongs to a clustering key
Find all tables with _AIRBYTE_EMITTED_AT column in Snowflake Run this query in Snowflake to find all affected tables:
Copy code
SELECT 
    table_schema,
    table_name,
    column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
Or across all schemas in your database:
Copy code
SELECT 
    table_schema,
    table_name,
    column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
ORDER BY table_schema, table_name;
Then fix each affected table For each table returned, run: [Forum Post]
Copy code
-- Step 1: Remove the clustering key
ALTER TABLE <your_schema>.<your_table> CLUSTER BY ();

-- Step 2: Drop the old column
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
After fixing all tables 1. ✅ Reset the connection in Airbyte UI 2. ✅ Trigger a new sync to confirm the error is resolved 3. ✅ Upgrade your Snowflake destination connector to the latest version to prevent this from recurring âš ī¸ Make sure to back up your data before making any manual DDL changes. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai it has 100 tables that have
airbyte_emitted_at column
and why some tables don't have it
k
Why some tables have _AIRBYTE_EMITTED_AT and others don't
_AIRBYTE_EMITTED_AT
is a pre-Destinations V2 metadata field. Tables that have it were created before your Snowflake destination was upgraded to Destinations V2. Tables that don't have it were created after the upgrade and use the newer
_airbyte_extracted_at
field instead. [Airbyte Metadata Fields] Fix all 100 tables at once Instead of running the fix manually for each table, you can generate and execute the statements dynamically:
Copy code
-- Step 1: Generate ALTER statements for all affected tables
SELECT 
    'ALTER TABLE ' || table_schema || '.' || table_name || ' CLUSTER BY ();' AS remove_cluster,
    'ALTER TABLE ' || table_schema || '.' || table_name || ' DROP COLUMN "_AIRBYTE_EMITTED_AT";' AS drop_column
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
This will generate the SQL statements for all 100 tables at once. You can then: 1. Copy the output 2. Review it carefully 3. Execute all statements in one go Important notes â€ĸ âš ī¸ Back up your data before running any DDL changes â€ĸ âš ī¸ Only drop the clustering key if
_AIRBYTE_EMITTED_AT
is the only clustering key — if other columns are also part of the clustering key, adjust accordingly â€ĸ ✅ After fixing all tables, reset and re-sync your connections in Airbyte UI â€ĸ ✅ Upgrade your Snowflake destination connector to the latest version to prevent this from recurring [Snowflake Destination] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai is there anything I need to put in the bracket after cluster by ()`ALTER TABLE <your_schema>.<your_table> CLUSTER BY ()`
k
The knowledge sources do not explicitly cover the exact Snowflake
CLUSTER BY ()
syntax details. However, based on the context from the forum post that resolved this issue: No — leave the brackets empty () The empty brackets
()
is the correct syntax to remove/drop the clustering key entirely from the table. [Forum Post]
Copy code
-- This removes the clustering key entirely
ALTER TABLE <your_schema>.<your_table> CLUSTER BY ();

-- Then drop the column
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
When would you put something in the brackets? You would only put column names inside the brackets if you want to set a new clustering key, for example:
Copy code
-- Setting a new clustering key
ALTER TABLE <your_schema>.<your_table> CLUSTER BY (some_other_column);
But in your case, since you just want to remove
_AIRBYTE_EMITTED_AT
as a clustering key so Airbyte can drop it, leaving the brackets empty is the correct approach. Recommendation I'd suggest verifying this syntax directly in the Snowflake documentation on ALTER TABLE to confirm, as the knowledge sources don't contain the full Snowflake DDL reference. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai why some tables with _SCD have data but some don't
k
The knowledge sources do not contain enough specific information to give a definitive answer for your exact situation. However, based on what the knowledge sources do tell us about
_SCD
tables: Why some _SCD tables have data and others don't 1. Basic Normalization was not selected for some tables The
_SCD
(history) table is only created and populated when Basic Normalization is enabled. If custom transformation was used instead, the
_SCD
table may be created but remain empty. [Forum Post] > When the data was synced, the sync process did not create intermediate table i.e, history table which ends with
_SCD
. Is it mandatory to select Basic Normalization? 2. Tables without primary keys won't populate
_SCD
tables
Tables that don't have a primary key defined cannot be loaded incrementally with deduplication, which means the
_SCD
table may not be populated. [Forum Post] > The source table needs to have a primary key to be loaded incrementally, because it's using the table primary key for downstream duplication if Incremental - Deduped history is enabled. 3.
_SCD
tables were removed in Destinations V2
Since you are using a newer version of the Snowflake destination connector,
_SCD
tables are no longer supported in Destinations V2. [Incremental Append Deduped] > Previous versions of Airbyte destinations supported SCD tables, which would store every entry seen for a record. This was removed with Destinations V2 and Typing and Deduplication. Bottom line The
_SCD
tables with data are likely leftover from a previous pre-Destinations V2 sync, while the empty ones were created under Destinations V2 where SCD tables are no longer populated. This is consistent with your earlier issue where some tables had
_AIRBYTE_EMITTED_AT
(old) and others didn't (new). 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai it won't have error if i drop
_AIRBYTE_EMITTED_AT
, right?
k
Based on the knowledge sources, dropping
_AIRBYTE_EMITTED_AT
should be safe because: Why it's safe to drop 1. It's a deprecated legacy field
_AIRBYTE_EMITTED_AT
is a pre-Destinations V2 field that has already been replaced by
_airbyte_extracted_at
in the current Destinations V2. [Airbyte Metadata Fields] >
_airbyte_emitted_at
and
_airbyte_extracted_at
are exactly the same, only the column name changed. 2. Airbyte is already trying to drop it automatically The error you are seeing (
Cannot drop column '_AIRBYTE_EMITTED_AT' which belongs to a clustering key
) means Airbyte itself is already attempting to drop this column during schema evolution — it just can't because of the clustering key. [Snowflake PR] 3. The fix specifically removes DROP logic The latest Snowflake destination connector (
4.0.47+
) removes the DROP logic entirely, meaning Airbyte will retain old columns instead of dropping them going forward. [Snowflake PR] Correct order of operations
Copy code
-- Step 1: Remove clustering key FIRST
ALTER TABLE <your_schema>.<your_table> CLUSTER BY ();

-- Step 2: Then drop the column
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
âš ī¸ One caution If you have any downstream models, dashboards, or dbt transformations that reference
_AIRBYTE_EMITTED_AT
, those will break after dropping the column. Replace any references with
_airbyte_extracted_at
instead. [Upgrading to Destinations V2] > You can replace all instances of
_airbyte_emitted_at
with
_airbyte_extracted_at
. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai should i drop clustering key for the tables with '_airbyte_raw_tablename'_
k
The knowledge sources do not explicitly cover whether you should drop clustering keys for
_airbyte_raw_*
tables specifically. However, based on what the knowledge sources tell us: Raw tables are managed by Airbyte internally
_airbyte_raw_*
tables are internal staging tables managed by Airbyte and are not intended to be modified directly. [Upgrading to Destinations V2] > We may make further changes to raw tables in the future, as these tables are intended to be a staging ground for Airbyte to optimize the performance of your syncs. We cannot guarantee the same level of stability as for final tables. My recommendation Only drop the clustering key if: â€ĸ ✅ The raw table has
_AIRBYTE_EMITTED_AT
as a clustering key â€ĸ ✅ The sync is failing because of it (as shown in your error logs) You should NOT need to touch raw tables if: â€ĸ ❌ The sync error is only occurring on the final tables â€ĸ ❌ The raw tables are not causing any errors To check if raw tables are affected Run this query to see if raw tables specifically have the clustering key issue:
Copy code
SELECT 
    table_schema,
    table_name,
    column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_name LIKE '%airbyte_raw%'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
If the query returns results and those tables are causing sync errors, then apply the same fix. Otherwise, I'd recommend leaving the raw tables untouched to avoid any unintended side effects. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai i dropped the column '_AIRBYTE_EMITTED_AT', then I need to retest the destination, right?
k
Yes, you should retest after dropping the column! Here is what to do: Steps to retest the destination 1. Reset the connection in Airbyte UI â€ĸ Go to Connections → select your connection â€ĸ Click Reset to clear the saved state â€ĸ This ensures Airbyte re-evaluates the destination schema [Schema Change Management] 2. Manually trigger a new sync â€ĸ After resetting, click Sync now to manually trigger a sync â€ĸ Monitor the logs closely to confirm the
Cannot drop column '_AIRBYTE_EMITTED_AT'
error is gone [Schema Change Management] 3. Verify the sync completes successfully Check the Timeline tab in your connection and confirm: 4. Verify data in Snowflake Run this query to confirm the column is gone and data is correct:
Copy code
SELECT *
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>';
This should return no results if the column was successfully dropped from all tables. âš ī¸ Reminder Don't forget to also set up the heartbeat table fix we discussed earlier to prevent the
Heartbeat not progressing
issue from recurring on the next sync. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai If i start a data sync, it will be full refresh or adding new data? By the way, there is no RESET button in the UI (version 2.1.1)
k
What happens when you start a sync now Since you are using Incremental | Append + Deduped mode, triggering a new sync will only add new/modified data since the last cursor state — it will not do a full refresh. [Incremental Append Deduped] > Incremental means syncing only replicates new or modified data. This prevents re-fetching data that you have already replicated from a source. About the Reset/Clear button in version 2.1.1 You are correct — in Airbyte v1.0.0 and later, the "Reset" button was replaced with "Clear". [Clearing Data] > As of Airbyte v1.0.0, the term "Clear" has replaced "Reset" in the Airbyte UI and documentation. So in your version (2.1.1), look for the "Clear" button instead: â€ĸ Go to Connections → select your connection â€ĸ Click the Settings tab â€ĸ Look for "Clear data" button Or to clear a single stream: â€ĸ Go to the Connection status page â€ĸ Click the three grey dots next to any stream â€ĸ Select "Clear data" Bottom line Since you already have 522,451 records loaded and just dropped the
_AIRBYTE_EMITTED_AT
column, I'd recommend: 1. ✅ Trigger a sync now (without clearing) to test if the error is resolved 2. ✅ Monitor the logs to confirm no
_AIRBYTE_EMITTED_AT
errors appear 3. ✅ Only do a Clear if the sync still fails 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai should i retest saved destination first?
k
Yes, retesting the saved destination first is a good idea before triggering a full sync! Here is how: Steps to retest the destination 1. Go to your Snowflake destination settings â€ĸ Click Destinations in the left navbar â€ĸ Select your Snowflake destination â€ĸ Click Test connection to verify Airbyte can still connect to Snowflake correctly 2. What the test checks â€ĸ ✅ Airbyte can connect to Snowflake â€ĸ ✅ Credentials are still valid â€ĸ ✅ Permissions are correct â€ĸ ✅ No configuration issues after the DDL changes you made 3. After the destination test passes â€ĸ Go to Connections → select your connection â€ĸ Click Sync now to trigger a new incremental sync â€ĸ Monitor the logs closely to confirm the
Cannot drop column '_AIRBYTE_EMITTED_AT'
error is gone Why this order matters The knowledge sources do not explicitly cover the exact destination test flow in version 2.1.1, so if you cannot find the Test connection button, it is likely located in your Snowflake destination settings page in the Airbyte UI. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai what does this warning mean 'Property 'flush.lsn.source' is set to 'false', the LSN will not be flushed to the database source and WAL logs will not be cleared. User is expected to handle this outside Debezium.'
k
What this warning means This warning appears in your logs because Airbyte intentionally sets
flush.lsn.source = false
in the Debezium configuration. Here is what it means: [Github Issue] Why Airbyte sets flush.lsn.source = false Airbyte deliberately disables Debezium from automatically flushing the LSN back to Postgres. This is a safety mechanism to prevent data loss: [Github Issue] >
flush.lsn.source = false
is needed to prevent situations where the replication slot is advanced and the data fails to be written to the destination, or the final state isn't written to the database correctly. How Airbyte handles LSN flushing instead Since Debezium is not allowed to flush the LSN, Airbyte handles it manually at the start of the next sync: [Github Issue] > The LSN is advanced on the startup of the subsequent sync. It seems counterintuitive, but this ensures that the previous job was successful, and the job state was written and then read back successfully. The flow in simple terms Why this matters for your situation This is directly related to the
Heartbeat not progressing
issue you saw earlier. Because
flush.lsn.source = false
, the WAL logs will not be cleared automatically — Airbyte needs at least two successful syncs to advance the replication slot. [Github Issue] This is also why setting up the heartbeat table is important — it ensures the LSN keeps advancing even when there are no new records to sync. [Postgres Troubleshooting] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai can i cancel this sync?
k
Yes, you can cancel the sync! There are two ways to do it: Option 1: Cancel from the Airbyte UI â€ĸ Go to Connections → select your connection â€ĸ On the Timeline or Status page, click the Cancel button on the running sync Option 2: Cancel via the Airbyte API Use the
DELETE /jobs/{jobId}
endpoint: [Airbyte API]
Copy code
DELETE /jobs/{jobId}
âš ī¸ Things to keep in mind before cancelling Based on your earlier experience: [Clearing Data] Recommendation Since you are still in the middle of testing after dropping
_AIRBYTE_EMITTED_AT
, I would suggest: 1. ✅ Let the sync run a bit longer to confirm the error is gone 2. ✅ Only cancel if you see the same
Cannot drop column '_AIRBYTE_EMITTED_AT'
error appearing again in the logs 3. ✅ Make sure the heartbeat table is set up before the next sync runs 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai should i disable this connection until the heartbeat table is set up
k
Yes, disabling the connection until the heartbeat table is set up is a good idea! Here is why: Why you should disable it first Based on what we have seen in your logs, without the heartbeat table: â€ĸ âš ī¸ The sync will get stuck with
Heartbeat not progressing
again â€ĸ âš ī¸ The
confirmed_flush_lsn
will keep advancing beyond the saved state LSN â€ĸ âš ī¸ WAL logs will not be cleared properly How to disable the connection In Airbyte v2.1.1: [Configuring Connections] 1. Go to Connections in the left navbar 2. Find and click your connection 3. Click Settings 4. Toggle the connection to disabled/paused This prevents any scheduled syncs from running automatically while you set up the heartbeat table. Setup checklist before re-enabling Do these steps in order: This way you avoid the same
Heartbeat not progressing
issue repeating on the next scheduled sync. [Postgres Troubleshooting] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai okay, i remember correctly the first sync was successful even though it had warnings via status of active streams in ui
k
Yes, that is consistent with what the knowledge sources tell us about warnings vs errors: Warnings do not stop a sync from succeeding Looking back at your situation, the first sync showed "Succeeded" status even with warnings because: [Connection Troubleshooting] > Airbyte shows sync errors in yellow. These can range from transient errors to warnings from the source, like rate limiting. In most cases, these types of errors resolve themselves without any action required. The difference between warnings and errors What likely happened in your case 1. ✅ First sync succeeded — 522,451 records loaded despite the
Heartbeat not progressing
warnings 2. âš ī¸ The warnings were about the CDC heartbeat and LSN flushing — these are non-fatal 3. ❌ The subsequent syncs started failing because the LSN issue accumulated over time without the heartbeat table in place This is exactly why setting up the heartbeat table is important — it prevents those warnings from eventually turning into hard failures on subsequent syncs. [Postgres Troubleshooting] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai the stats below
k
Your screenshot shows a mix of Queued and Syncing streams. Here is what this means: What you are seeing This is completely normal behavior for a sync with multiple streams! [Connection Status] > Stream-level "Queued" status means the stream is waiting to sync within an active connection sync.

docs.airbyte.com/assets/images/sync-progresâ€Ļ▾

What this tells us â€ĸ ✅ The sync is actively running — 4 streams are currently syncing â€ĸ ✅ The queued streams are waiting their turn within the same sync job â€ĸ ✅ This is not the capacity-based queuing issue (Cloud Pro/Enterprise Flex) — that would show at the connection level, not stream level What to monitor Since you just dropped
_AIRBYTE_EMITTED_AT
and started a new sync, watch the logs closely for: 1. ✅ No
Cannot drop column '_AIRBYTE_EMITTED_AT'
errors 2. ✅ All streams eventually move from Queued → Syncing → Synced 3. âš ī¸ Any
Heartbeat not progressing
warnings in the logs image 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai it's still throwing '`Heartbeat not progressing` ', can i cancel the sync?
k
Yes, you can cancel the sync now! Here is what to do: Cancel the sync immediately â€ĸ Go to Connections → select your connection â€ĸ Click Cancel on the running sync in the Timeline or Status page The data already loaded before cancellation will remain safely in Snowflake and the cursor state will be saved. [Airbyte API] After cancelling — do these steps in order This time, do not re-enable the connection until the heartbeat table is fully set up: [Postgres Troubleshooting] Step 1: Create the heartbeat table in Postgres
Copy code
CREATE TABLE public.airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);
Step 2: Add it to your publication
Copy code
ALTER PUBLICATION <publicationName> ADD TABLE public.airbyte_heartbeat;
Step 3: Configure Debezium heartbeat query in Airbyte UI â€ĸ Go to Sources → select your Postgres source â€ĸ Go to Advanced settings → Update Method â€ĸ Under Debezium heartbeat query enter:
Copy code
INSERT INTO public.airbyte_heartbeat (text) VALUES ('heartbeat')
Step 4: Re-enable the connection and trigger a manual sync Why this keeps happening without the heartbeat table 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai step 1-3 done, retested the source and it's passed
k
Great progress! Here is what to do next: Step 4: Re-enable and test the connection 1. Disable/pause is no longer needed — re-enable the connection â€ĸ Go to Connections → select your connection â€ĸ Go to Settings â€ĸ Toggle the connection back to enabled 2. Trigger a manual sync â€ĸ Click Sync now to manually trigger a new sync â€ĸ Do not wait for the scheduled sync — test it manually first 3. Monitor the logs closely for Quick checklist before syncing â€ĸ ✅
airbyte_heartbeat
table created in Postgres â€ĸ ✅ Table added to publication â€ĸ ✅ Debezium heartbeat query configured in Postgres source â€ĸ ✅ Source connection test passed â€ĸ ✅
_AIRBYTE_EMITTED_AT
column dropped from all 100 tables â€ĸ âŦœ Connection re-enabled â€ĸ âŦœ Manual sync triggered and confirmed successful Let me know how the sync goes! [Postgres Troubleshooting] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai how would this data sync be after cancelling?
k
Based on what we have discussed throughout this conversation, here is what to expect: What happens after cancelling and re-syncing Since you are using Incremental | Append + Deduped mode, the next sync will: What is different this time Compared to your previous cancelled syncs, this sync should now be: 1. ✅ No
Heartbeat not progressing
warnings — heartbeat table is set up 2. ✅ No
Cannot drop column '_AIRBYTE_EMITTED_AT'
errors — column dropped from all 100 tables 3. ✅ LSN will advance properly — Debezium heartbeat query is configured 4. ✅ WAL logs will be cleared — on the startup of the next subsequent sync [Incremental Append Deduped] Expected sync flow
Copy code
Previous cancelled sync state
        ↓
Airbyte reads cursor value from last saved state
        ↓
Only fetches records newer than last cursor value
        ↓
Appends new records to Snowflake
        ↓
Deduplicates final table by primary key
        ↓
Saves new cursor state
This should be a much faster and cleaner sync than before! Let me know how it goes. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai I noticed these
k
You have two separate issues showing in your logs: Issue 1: Type [oid:...] is already mapped (First screenshot) These are harmless warnings from Debezium's TypeRegistry. They appear because Debezium is trying to register PostgreSQL types that are already registered. [Github Issue] > These warnings do not affect the sync and can be safely ignored. Issue 2: Could not execute heartbeat action (Error: 42501) permission denied for sequence airbyte_heartbeat_id_seq âš ī¸ (Second screenshot) This is the critical issue that needs to be fixed immediately. The Airbyte user does not have permission to insert into the
airbyte_heartbeat
table sequence. Fix — Grant the missing permissions Run these SQL statements in your Postgres database:
Copy code
-- Grant usage on the schema
GRANT USAGE ON SCHEMA public TO <airbyte_user>;

-- Grant permissions on the heartbeat table
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLE public.airbyte_heartbeat TO <airbyte_user>;

-- Grant permissions on the sequence (this is what's failing)
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
Replace
<airbyte_user>
with your actual Airbyte database user. [Postgres Troubleshooting] After fixing permissions 1. ✅ Retest the Postgres source connection 2. ✅ Trigger a manual sync 3. ✅ Confirm
Could not execute heartbeat action
error is gone from logs 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai i granted INSERT, UPDATE to the user
k
Granting
INSERT
and
UPDATE
is a good start, but based on the error you saw, you also need to grant permissions on the sequence specifically, as that is what was failing: The sequence permission is still needed The error was: >
permission denied for sequence airbyte_heartbeat_id_seq
This means the
INSERT
permission alone is not enough because the
id
column uses
SERIAL
which relies on a sequence to auto-generate IDs. You need to explicitly grant access to the sequence too:
Copy code
-- This is the missing permission that caused the error
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
Full set of permissions needed
Copy code
-- Table permissions
GRANT INSERT, UPDATE, SELECT ON TABLE public.airbyte_heartbeat TO <airbyte_user>;

-- Sequence permission (critical - this was the failing part)
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
After granting sequence permission 1. ✅ Retest the Postgres source connection 2. ✅ Trigger a manual sync 3. ✅ Confirm
Could not execute heartbeat action
error is gone from logs The sync should now proceed without the heartbeat permission error. [Postgres Troubleshooting] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai should I create the table
airbyte_heartbeat_id_seq
first?
k
No, you do not need to create
airbyte_heartbeat_id_seq
manually! Here is why: It was already created automatically When you ran this earlier in Step 1:
Copy code
CREATE TABLE public.airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);
The
SERIAL
keyword automatically creates the sequence
airbyte_heartbeat_id_seq
for you. It is already there — you just need to grant permissions on it. [Postgres Troubleshooting] Just run the grant statement
Copy code
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
You can verify it exists by running
Copy code
SELECT sequence_name 
FROM information_schema.sequences 
WHERE sequence_name = 'airbyte_heartbeat_id_seq';
If it returns a result, the sequence is already there and you just need to grant the permissions. ✅ 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai as per our conversation, is there anything you forgot to mention to avoid any errors?
k
Based on our entire conversation, here are a few things worth double-checking to avoid any errors: 1. âš ī¸ Verify _AIRBYTE_EMITTED_AT is dropped from ALL 100 tables Run this query to confirm no tables still have the column:
Copy code
SELECT 
    table_schema,
    table_name,
    column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
This should return zero results. 2. âš ī¸ Verify heartbeat table is added to the publication Confirm the heartbeat table was added correctly:
Copy code
SELECT * FROM pg_publication_tables 
WHERE tablename = 'airbyte_heartbeat';
3. âš ī¸ Sequence permission still needs to be granted As we just discussed, make sure you run:
Copy code
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
4. âš ī¸ Downstream models referencing _AIRBYTE_EMITTED_AT If you have any dbt models, dashboards, or transformations referencing
_AIRBYTE_EMITTED_AT
, they will break. Replace all references with
_airbyte_extracted_at
instead. [Upgrading to Destinations V2] 5. âš ī¸ Retest the Postgres source after granting sequence permission After granting the sequence permission: â€ĸ ✅ Retest the Postgres source connection â€ĸ ✅ Retest the Snowflake destination connection â€ĸ ✅ Then trigger a manual sync Full checklist before triggering sync 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai I got another one: Warning from destination: SQL compilation error: error line 59 at position 2 invalid identifier '_AIRBYTE_RAW_ID'
k
Based on the knowledge sources, this error is related to a known issue with missing meta columns when upgrading from older versions of the Snowflake destination connector. What this error means The error
invalid identifier '_AIRBYTE_RAW_ID'
means the
_AIRBYTE_RAW_ID
meta column is missing from one or more of your Snowflake tables. This happens when upgrading from pre-3.10.0 tables to 4.0.0+ because the
SnowflakeAbMetaAndGenIdMigration
was removed without replacement. [Snowflake PR] > Snowflake destination fails when upgrading from pre-3.10.0 tables to Direct Load 4.0.0+ because
_AIRBYTE_META
and
_AIRBYTE_GENERATION_ID
columns are missing but the
COPY INTO
statement references them. Missing meta columns to check The affected meta columns are: [Airbyte Metadata Fields] Fix — Add missing meta columns First, identify which tables are missing the column:
Copy code
SELECT table_name
FROM information_schema.tables t
WHERE table_schema = '<your_schema>'
AND NOT EXISTS (
    SELECT 1 
    FROM information_schema.columns c
    WHERE c.table_name = t.table_name
    AND c.table_schema = t.table_schema
    AND c.column_name = '_AIRBYTE_RAW_ID'
);
Then add the missing columns to affected tables:
Copy code
-- Add all missing meta columns
ALTER TABLE <your_schema>.<your_table> 
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Long term fix The permanent fix is available in destination-snowflake 4.0.45+ which automatically adds missing meta columns on the first sync. [Snowflake PR] > Missing meta columns are automatically added on first sync. Updated checklist 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai other than the '`__airbyte__raw_id'` error, I got another error below
k
The error in your screenshot is: >
ERROR Error closing resource io.airbyte.container.orchestrator.worker.io.LocalContainerAirbyteDestination@3054cdd3; recording failure but continuing.
What this error means This is a secondary error that occurs as a consequence of the primary error (
invalid identifier '_AIRBYTE_RAW_ID'
). When the destination connector fails, Airbyte tries to close the destination resource but cannot do so cleanly, resulting in this error. [Github Issue] > This error typically appears after the root cause error and is not the primary issue itself. This is not the root cause Looking at the pattern from our earlier discussion, this error has appeared consistently across multiple issues: What to do Fix the root cause first — the
_AIRBYTE_RAW_ID
missing column issue we just discussed:
Copy code
ALTER TABLE <your_schema>.<your_table> 
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Once the
_AIRBYTE_RAW_ID
error is resolved, this
Error closing resource
error should automatically disappear as well. [Github Issue] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai in this case,
_AIRBYTE_META
and
_AIRBYTE_GENERATION_ID
columns are missing but the
COPY INTO
statement references them, so i don't need to worry about these 2 columns, just to add missing column
_AIRBYTE_RAW_ID
k
Based on the knowledge sources, I would not recommend only adding
_AIRBYTE_RAW_ID
. Here is why: All missing meta columns need to be added The PR fix specifically mentions both
_AIRBYTE_META
and
_AIRBYTE_GENERATION_ID
as missing columns that cause the
COPY INTO
failure: [Snowflake PR] > Snowflake destination fails when upgrading from pre-3.10.0 tables to Direct Load 4.0.0+ because
_AIRBYTE_META
and
_AIRBYTE_GENERATION_ID
columns are missing
but the
COPY INTO
statement references them, causing
SQL compilation error: invalid identifier '_AIRBYTE_META'
. The COPY INTO statement references ALL meta columns Looking at the expected meta columns for schema mode: [SnowflakeColumnManager] Recommendation Run the query to check all missing meta columns across your tables first:
Copy code
SELECT 
    table_name,
    MAX(CASE WHEN column_name = '_AIRBYTE_RAW_ID' THEN 'EXISTS' ELSE 'MISSING' END) AS raw_id,
    MAX(CASE WHEN column_name = '_AIRBYTE_EXTRACTED_AT' THEN 'EXISTS' ELSE 'MISSING' END) AS extracted_at,
    MAX(CASE WHEN column_name = '_AIRBYTE_META' THEN 'EXISTS' ELSE 'MISSING' END) AS meta,
    MAX(CASE WHEN column_name = '_AIRBYTE_GENERATION_ID' THEN 'EXISTS' ELSE 'MISSING' END) AS generation_id
FROM information_schema.columns
WHERE table_schema = '<your_schema>'
AND column_name IN ('_AIRBYTE_RAW_ID', '_AIRBYTE_EXTRACTED_AT', '_AIRBYTE_META', '_AIRBYTE_GENERATION_ID')
GROUP BY table_name
ORDER BY table_name;
Then add all missing columns at once to avoid hitting the same error again on the next sync:
Copy code
ALTER TABLE <your_schema>.<your_table>
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT,
    ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Adding only
_AIRBYTE_RAW_ID
risks hitting the same
invalid identifier
error
for
_AIRBYTE_META
or
_AIRBYTE_GENERATION_ID
on the very next sync. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai i checked a few table in snowflake and they have these columns before upgrading it, and it's a must but not a smart way to add these columns for 60 tables
k
You are right, manually adding columns to 60 tables is not efficient! Here is a smarter way to do it: Generate ALTER TABLE statements automatically Run this query in Snowflake to auto-generate the
ALTER TABLE
statements for all affected tables at once:
Copy code
SELECT 
    'ALTER TABLE ' || '"' || table_schema || '"."' || table_name || '"' ||
    ' ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR' ||
    ', ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ' ||
    ', ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT' ||
    ', ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;' AS alter_statement
FROM information_schema.tables
WHERE table_schema = '<your_schema>'
AND table_type = 'BASE TABLE'
AND NOT EXISTS (
    SELECT 1 
    FROM information_schema.columns c
    WHERE c.table_name = tables.table_name
    AND c.table_schema = tables.table_schema
    AND c.column_name = '_AIRBYTE_RAW_ID'
)
ORDER BY table_name;
What this does Then execute all generated statements 1. ✅ Copy the output from the query 2. ✅ Paste and run all generated
ALTER TABLE
statements at once 3. ✅ Verify with the check query from earlier to confirm all columns are present This way you handle all 60 tables in one shot without manually writing each statement. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai I ran one
alter table
statement and got an error: SQL compilation error: syntax error line 3919 at position 85 unexpected 'COLUMN'. syntax error line 1 at position 99 unexpected 'EXISTS'. syntax error line 1 at position 148 unexpected 'COLUMN'. syntax error line 1 at position 162 unexpected 'EXISTS'. syntax error line 1 at position 198 unexpected 'COLUMN'. syntax error line 1 at position 212 unexpected 'EXISTS'.
k
The error is because Snowflake does not support adding multiple columns with
ADD COLUMN IF NOT EXISTS
in a single
ALTER TABLE
statement. You need to use separate
ALTER TABLE
statements
for each column. Fix — Use separate statements per column
Copy code
ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR;
ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ;
ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT;
ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Updated auto-generate query for all 60 tables Use this query to generate separate statements for each column per table:
Copy code
SELECT 
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR;' || chr(10) ||
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ;' || chr(10) ||
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT;' || chr(10) ||
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;' AS alter_statements
FROM information_schema.tables
WHERE table_schema = '<your_schema>'
AND table_type = 'BASE TABLE'
AND NOT EXISTS (
    SELECT 1 
    FROM information_schema.columns c
    WHERE c.table_name = tables.table_name
    AND c.table_schema = tables.table_schema
    AND c.column_name = '_AIRBYTE_RAW_ID'
)
ORDER BY table_name;
Steps 1. ✅ Run the query above to generate all statements 2. ✅ Copy the output and run all generated statements at once 3. ✅ Verify all columns are added with the check query from earlier This follows the same SQL pattern used in the Snowflake destination fix. [Snowflake PR] 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
@kapa.ai the thing is there are 67 tables ending with '`_SCD`' don't have these columns
k
The knowledge sources do not explicitly mention
_SCD
tables in relation to this issue. However, based on what we know: About _SCD tables
_SCD
(Slowly Changing Dimension) tables are legacy tables created by older versions of Airbyte's normalization process. In newer versions of Airbyte (Destinations V2), SCD tables are no longer used. [Upgrading to Destinations V2] My recommendation âš ī¸ I would not recommend adding meta columns to
_SCD
tables because: What to do instead 1. ✅ Only add meta columns to the 60 non-SCD tables using the auto-generate query from earlier 2. ✅ Modify the query to exclude
_SCD
tables:
Copy code
SELECT 
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR;' || chr(10) ||
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ;' || chr(10) ||
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT;' || chr(10) ||
    'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;' AS alter_statements
FROM information_schema.tables
WHERE table_schema = '<your_schema>'
AND table_type = 'BASE TABLE'
AND table_name NOT LIKE '%_SCD'
AND NOT EXISTS (
    SELECT 1 
    FROM information_schema.columns c
    WHERE c.table_name = tables.table_name
    AND c.table_schema = tables.table_schema
    AND c.column_name = '_AIRBYTE_RAW_ID'
)
ORDER BY table_name;
However, I would strongly suggest confirming with Airbyte support whether
_SCD
tables need to be handled differently in your specific upgrade path, as the knowledge sources do not explicitly cover this scenario. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
m
@kapa.ai finally it works
k
That is great news! 🎉 What you accomplished today It was a long troubleshooting session but you successfully resolved multiple issues: Going forward — things to monitor 1. ✅ WAL logs — should now be cleared properly on subsequent syncs 2. ✅ Incremental syncs — should run cleanly without errors 3. ✅ Downstream models — make sure any dbt/SQL models reference
_airbyte_extracted_at
instead of
_airbyte_emitted_at
4. ✅ _SCD tables — monitor if they cause any issues in future syncs Great job working through all those issues! Let me know if you run into anything else. 🚀 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements