This message was deleted.

Looking at your log output, I can see that the Snowflake JDBC driver is reporting

private key is not provided

even though

private key file: rsa_key.p8

is set. This is a known pattern with key pair authentication in Airbyte's Snowflake connectors. Key Observations from Your Log 1.

private key is not provided

— Despite

private key file: rsa_key.p8

being listed, the JDBC driver logs this message, which typically indicates the key could not be parsed/loaded correctly. 2. No passphrase —

private key pwd is not provided

, meaning you're using an unencrypted key (or the passphrase isn't being passed through). Possible Causes & Solutions 1. Encrypted Key Parsing Issue (Most Likely) If your key was generated with encryption (e.g., using AES-256 or DES3), the connector may fail to parse it without Bouncy Castle enabled. There is a known issue where keys generated with OpenSSL 3.x using encryption cannot be used without enabling Bouncy Castle support, resulting in errors like: >

Private key provided is invalid or not supported: PBE parameter parsing error: expecting the object identifier for AES cipher

[source-snowflake key issue] A fix enabling Bouncy Castle for the destination connector was merged (PR #77978), but the source connector already had it enabled. [Bouncy Castle fix] 2. Key Generation Make sure your private key is generated correctly. For an unencrypted key:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt

For an encrypted key:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -v2 aes-256-cbc -out rsa_key.p8

Then generate the public key:

openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

And assign it to your Snowflake user:

alter user AIRBYTE_KEYPAIR set rsa_public_key=<public_key_value>;

[key pair auth docs] 3. Troubleshooting Steps • Verify the public key is correctly assigned to the

AIRBYTE_KEYPAIR

user in Snowflake. • If using an encrypted key, ensure the passphrase is provided in the connector configuration. • Refer to Snowflake's key pair auth troubleshooting docs for additional guidance. If you're on an older connector version, upgrading to the latest version of the Snowflake connector may resolve parsing issues with certain key formats. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai it is a encrypted key, the funniest is that airbyte created schema and loaded rows in SNowflake, but the job still running

That's an interesting situation — the sync appears to have functioned (schema created, rows loaded) but the job is stuck in a "Running" state. This is a separate issue from the key parsing problem. Looking at the knowledge sources, there are reports of Airbyte syncs getting stuck in the "Running" state with Snowflake destination, even when data is actually being written. This has been observed in Kubernetes deployments and can relate to resource constraints or internal task coordination issues. [syncs hanging] However, the knowledge sources don't contain enough specific information to definitively explain why your particular job is stuck after successfully loading data with an encrypted key pair. A few things worth noting from the available information: 1. The encrypted key warning — Your logs show

WARNING: Extract private key from file: File rsa_key.p8 is accessible by others to: read

. This is a warning from the Snowflake JDBC driver about file permissions, not necessarily a fatal error, which is consistent with the fact that data was still loaded. [wrong error logs issue] 2. Job stuck after data load — This pattern (data written but job not completing) has been seen before and is typically unrelated to authentication. It may be a checkpoint/state finalization issue. Recommended next steps: • Check if the job eventually times out and retries, or if it needs to be manually cancelled. • Review the full sync logs for any errors after the data load phase (e.g., checkpoint flushing, stream closing). • Try cancelling the stuck sync and re-running it to see if it completes cleanly on a fresh attempt. • If you're on a self-hosted deployment, consider upgrading to the latest Snowflake destination connector version, as the Bouncy Castle fix (PR #77978) was included in

destination-snowflake 4.0.42

. [Bouncy Castle fix] If the issue persists, I'd recommend opening a GitHub issue with your full sync logs for the Airbyte team to investigate. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai maybe is a problm of self hosted mongo

That's a valid consideration. There are indeed known limitations with the self-hosted MongoDB connector in Airbyte that could contribute to sync issues. Known Self-Hosted MongoDB Limitations 1. Self-Signed SSL Certificates Not Supported > Airbyte does not support self-signed SSL certificates for SSH tunnels. [vendor-specific limitations] 2. TLS/SSL Required TLS/SSL is required by the connector. If your self-hosted MongoDB instance doesn't have TLS/SSL properly configured, the connection may behave unexpectedly. [MongoDB troubleshooting] 3. replicaSet Parameter Not Passed to Debezium (CDC) There is a known bug (now closed) where the

replicaSet

parameter in the connection string was not correctly passed to the Debezium CDC engine for self-managed replica sets, causing incremental syncs to fail with:

Connector configuration is not valid. Replica set not specified in connection string for REPLICA_SET cluster.

[replicaSet CDC bug] 4. Oplog Retention If your self-hosted MongoDB oplog retention is too short, CDC incremental syncs can fail with an "invalid resume token" error. Airbyte recommends at least 24 hours (ideally 1 week) of oplog retention. [MongoDB troubleshooting] Could you share more details about your self-hosted MongoDB setup (e.g., are you using CDC/incremental sync, and do you see any specific errors in the MongoDB source logs)? That would help narrow down the root cause. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai what I got from mongo logs: 2026-05-14 170906 source INFO Reading messages from protocol version 0.2.0 2026-05-14 170906 source INFO main i.a.i.s.m.MongoDbSource(main):53 starting source: class io.airbyte.integrations.source.mongodb.MongoDbSource 2026-05-14 170906 source INFO main i.a.c.i.b.IntegrationCliParser$Companion(parseOptions):144 integration args: {check=null, config=/config/connectionConfiguration.json} 2026-05-14 170906 source INFO main i.a.c.i.b.IntegrationRunner(runInternal):130 Running integration: io.airbyte.integrations.source.mongodb.MongoDbSource 2026-05-14 170906 source INFO main i.a.c.i.b.IntegrationRunner(runInternal):131 Command: CHECK 2026-05-14 170906 source INFO main i.a.c.i.b.IntegrationRunner(runInternal):132 Integration config: IntegrationConfig{command=CHECK, configPath='/config/connectionConfiguration.json', catalogPath='null', statePath='null'} 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword order - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword group - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword display_type - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword airbyte_secret - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword always_show - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword min - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword max - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source WARN main c.n.s.UnknownKeywordFactory(lambda$getKeyword$0):37 Unknown keyword groups - you should define your own Meta Schema. If the keyword is irrelevant for validation, just use a NonValidationKeyword or if it should generate annotations AnnotationKeyword 2026-05-14 170906 source INFO main c.m.i.d.l.SLF4JLogger(info):71 MongoClient with metadata {"driver": {"name": "mongo-java-driver|sync|Airbyte", "version": "4.11.0"}, "os": {"type": "Linux", "name": "Linux", "architecture": "amd64", "version": "5.14.0-611.30.1.el9_7.x86_64"}, "platform": "Java/Amazon.com Inc./21.0.6+7-LTS"} created with settings MongoClientSettings{readPreference=ReadPreference{name=secondaryPreferred, hedgeOptions=null}, writeConcern=WriteConcern{w=null, wTimeout=null ms, journal=null}, retryWrites=true, retryReads=true, readConcern=ReadConcern{level=null}, credential=MongoCredential{mechanism=null, userName='glvox', source='glvox', password=<hidden>, mechanismProperties=<hidden>}, transportSettings=null, streamFactoryFactory=null, commandListeners=[], codecRegistry=ProvidersCodecRegistry{codecProviders=[ValueCodecProvider{}, BsonValueCodecProvider{}, DBRefCodecProvider{}, DBObjectCodecProvider{}, DocumentCodecProvider{}, CollectionCodecProvider{}, IterableCodecProvider{}, MapCodecProvider{}, GeoJsonCodecProvider{}, GridFSFileCodecProvider{}, Jsr310CodecProvider{}, JsonObjectCodecProvider{}, BsonCodecProvider{}, EnumCodecProvider{}, com.mongodb.client.model.mql.ExpressionCodecProvider@547c04c4, com.mongodb.Jep395RecordCodecProvider@30e92cb9, com.mongodb.KotlinCodecProvider@7fae4d4a]}, loggerSettings=LoggerSettings{maxDocumentLength=1000}, clusterSettings={hosts=[10.21.28.203:27017], srvServiceName=mongodb, mode=SINGLE, requiredClusterType=UNKNOWN, requiredReplicaSetName='null', serverSelector='null', clusterListeners='[]', serverSelectionTimeout='30000 ms', localThreshold='15 ms'}, socketSettings=SocketSettings{connectTimeoutMS=10000, readTimeoutMS=0, receiveBufferSize=0, proxySettings=ProxySettings{host=null, port=null, username=null, password=null}}, heartbeatSocketSettings=SocketSettings{connectTimeoutMS=10000, readTimeoutMS=10000, receiveBufferSize=0, proxySettings=ProxySettings{host=null, port=null, username=null, password=null}}, connectionPoolSettings=ConnectionPoolSettings{maxSize=100, minSize=0, maxWaitTimeMS=120000, maxConnectionLifeTimeMS=0, maxConnectionIdleTimeMS=0, maintenanceInitialDelayMS=0, maintenanceFrequencyMS=60000, connectionPoolListeners=[], maxConnecting=2}, serverSettings=ServerSettings{heartbeatFrequencyMS=10000, minHeartbeatFrequencyMS=500, serverListeners='[]', serverMonitorListeners='[]'}, sslSettings=SslSettings{enabled=false, invalidHostNameAllowed=false, context=null}, applicationName='null', compressorList=[], uuidRepresentation=UNSPECIFIED, serverApi=null, autoEncryptionSettings=null, dnsClient=null, inetAddressResolver=null, contextProvider=null} 2026-05-14 170906 source INFO main c.m.i.d.l.SLF4JLogger(info):71 No server chosen by ReadPreferenceServerSelector{readPreference=primary} from cluster description ClusterDescription{type=UNKNOWN, connectionMode=SINGLE, serverDescriptions=[ServerDescription{address=10.21.28.203:27017, type=UNKNOWN, state=CONNECTING}]}. Waiting for 30000 ms before timing out 2026-05-14 170906 source INFO cluster-ClusterId{value='6a062be00762b426d65abc29', description='null'}-10.21.28.203:27017 c.m.i.d.l.SLF4JLogger(info):71 Monitor thread successfully connected to server with description ServerDescription{address=10.21.28.203:27017, type=REPLICA_SET_SECONDARY, state=CONNECTED, ok=true, minWireVersion=0, maxWireVersion=17, maxDocumentSize=16777216, logicalSessionTimeoutMinutes=30, roundTripTimeNanos=88697458, setName='rs0', canonicalAddress=10.21.28.203:27017, hosts=[10.21.28.202:27017, 10.21.28.203:27017], passives=[], arbiters=[10.21.28.203:27018], primary='10.21.28.202:27017', tagSet=TagSet{[]}, electionId=null, setVersion=1, topologyVersion=TopologyVersion{processId=68964635486301c2f97a08b5, counter=4}, lastWriteDate=Thu May 14 200902 UTC 2026, lastUpdateTimeNanos=7175151473811043} 2026-05-14 170906 source INFO main i.a.i.s.m.MongoDbSource(check):82 Found authorized collections in database: glvox 2026-05-14 170906 source INFO main i.a.i.s.m.MongoDbSource(check):118 The source passed the check operation test! 2026-05-14 170906 source INFO main i.a.c.i.b.IntegrationRunner(runInternal):224 Completed integration: io.airbyte.integrations.source.mongodb.MongoDbSource 2026-05-14 170906 source INFO main i.a.i.s.m.MongoDbSource(main):55 completed source: class io.airbyte.integrations.source.mongodb.MongoDbSource

Your MongoDB source check is passing successfully — the logs confirm: • The connector connected to your self-hosted MongoDB replica set (

rs0

) at

10.21.28.203:27017

• Authorized collections were found in the

glvox

database • The check operation completed with

SUCCEEDED

However, there are two things worth noting from your logs: 1. SSL is Disabled

sslSettings=SslSettings{enabled=false, ...}

The connector is connecting without TLS/SSL. The documentation states that TLS/SSL is required by the connector [MongoDB troubleshooting]. While the check passed, this could cause issues during actual syncs, especially for CDC/incremental mode. 2. Cluster Mode is SINGLE (Not Replica Set Mode)

mode=SINGLE, requiredClusterType=UNKNOWN, requiredReplicaSetName='null'

The client was initialized in

SINGLE

mode without specifying the replica set name. However, the monitor thread did discover it as a

REPLICA_SET_SECONDARY

, and the check passed the replica set validation. This is consistent with the

check()

code — it queries for authorized collections first, which forces cluster discovery, and then validates the cluster type. [MongoDbSource check] What This Means The check passes, so the connection itself is fine. If your sync job is still stuck (as mentioned earlier), the issue is likely not with the MongoDB source check — it's more likely on the Snowflake destination side or in the sync orchestration layer. The MongoDB source logs you shared show a clean, successful check run. To further diagnose the stuck sync, I'd recommend looking at the sync logs during the READ phase (not just the CHECK phase), as those would show what happens when data is actually being read and sent to Snowflake. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.