@kapa.ai sync is not starting, in server log i can see: 2026-03-23 133139,918 [io-executor-thread-5] INFO i.a.c.s.RemoteDefinitionsProvider(getRemoteConnectorRegistry):207 - Fetched latest remote definitions (-269207054) 2026-03-23 133139,960 [io-executor-thread-4] INFO i.a.c.s.RemoteDefinitionsProvider(getRemoteConnectorRegistry):207 - Fetched latest remote definitions (-269207054) 2026-03-23 133152,788 [io-executor-thread-9] WARN i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}} 2026-03-23 133156,642 [io-executor-thread-7] WARN i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}} 2026-03-23 133221,885 [io-executor-thread-5] WARN i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}} 2026-03-23 133225,293 [scheduler-executor-thread-1] INFO i.a.c.t.TemporalClient(startNewManualSync):223 - Manual sync request 2026-03-23 133227,964 [scheduler-executor-thread-1] INFO i.a.c.t.ConnectionManagerUtils(signalWorkflowAndRepairIfNecessary):84 - Retrieved existing connection manager workflow for connection ac671838-4268-461d-954d-6cc4612aeae5. Executing signal. 2026-03-23 133230,119 [io-executor-thread-3] WARN i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}} 2026-03-23 133325,105 [io-executor-thread-1] WARN i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}} 2026-03-23 133325,663 [io-executor-thread-5] WARN i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}} 2026-03-23 133328,679 [io-executor-thread-2] WARN i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}} what is the problem?

The

WARN

messages you're seeing in the logs:

i.a.c.j.JsonSchemas(traverseJsonSchemaInternal):182 - The object is a properties key or a combo keyword. The traversal is silently stopped. Current schema: {"type":"object","additionalProperties":{"type":"object","properties":{},"additionalProperties":true}}

are a known warning in Airbyte. This warning appears when the JSON schema traversal encounters an object that is a

properties

key or a combo keyword, causing the traversal to stop silently. [sync jobs hanging] [IRSA permissions issue] However, based on the knowledge sources, this warning alone is not necessarily the root cause of syncs not starting. It has been observed appearing in logs alongside other unrelated issues (e.g., hanging syncs, permission problems, post-upgrade failures). The warning itself appears to be a benign/informational schema traversal notice rather than a fatal error. Looking at your logs more carefully, the sync was signaled (

Manual sync request

and

Executing signal

are both logged), but it doesn't appear to proceed further. A similar issue was reported after an Airbyte upgrade where syncs didn't start. [syncs after upgrade] What you can try: 1. Check if this started after an Airbyte upgrade — the issue has been reported in that context. 2. Look for additional errors beyond the

JsonSchemas

warnings in your logs, as the root cause is likely elsewhere (e.g., Temporal workflow issues, database connectivity, worker pod problems). 3. Check your worker/pod logs for more specific errors, especially if you're running on Kubernetes (EKS/GKE), as IAM/workload identity permission issues have also been associated with syncs not starting. [IRSA permissions issue] The knowledge sources do not contain enough information to definitively identify the exact root cause of your specific sync-not-starting issue beyond what is described above. I'd recommend checking the full server and worker logs for additional error messages beyond the

JsonSchemas

warnings. 👍 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 i can see this in worker log: 2026-03-23 133904,947 [workflow-method-connection_manager_85a6bf29-8d6b-4051-be72-ab422ac...-94ff317c-7374-42bf-8e72-93256640a131] ERROR i.a.w.t.s.ConnectionManagerWorkflowImpl(runMandatoryActivityWithOutput):822 - [ACTIVITY-FAILURE] Connection null failed to run an activity.(AutoDisableConnectionActivityInput). Connection manager workflow will be restarted after a delay of PT10M. io.temporal.failure.ActivityFailure: Activity with activityType='AutoDisableFailingConnection' failed: 'Activity task failed'. scheduledEventId=42, startedEventId=43, activityId=14215a79-ed5b-3e6c-a478-cdb29854f89d, identity='1@airbyte-worker-9876b68b9-9f87t', retryState=RETRY_STATE_MAXIMUM_ATTEMPTS_REACHED at java.base/java.lang.Thread.getStackTrace(Thread.java:2451) at io.temporal.internal.sync.ActivityStubBase.execute(ActivityStubBase.java:49) at io.temporal.internal.sync.ActivityInvocationHandler.lambda$getActivityFunc$0(ActivityInvocationHandler.java:83) at io.temporal.internal.sync.ActivityInvocationHandlerBase.invoke(ActivityInvocationHandlerBase.java:68) at jdk.proxy2/jdk.proxy2.$Proxy100.autoDisableFailingConnection(Unknown Source) at io.airbyte.workers.temporal.scheduling.ConnectionManagerWorkflowImpl.failJob$lambda$7(ConnectionManagerWorkflowImpl.kt:541) at io.airbyte.workers.temporal.scheduling.ConnectionManagerWorkflowImpl.runMandatoryActivityWithOutput(ConnectionManagerWorkflowImpl.kt:819) at io.airbyte.workers.temporal.scheduling.ConnectionManagerWorkflowImpl.failJob(ConnectionManagerWorkflowImpl.kt:539) at io.airbyte.workers.temporal.scheduling.ConnectionManagerWorkflowImpl.reportFailure(ConnectionManagerWorkflowImpl.kt:491) at io.airbyte.workers.temporal.scheduling.ConnectionManagerWorkflowImpl.reportFailure$default(ConnectionManagerWorkflowImpl.kt:428) at io.airbyte.workers.temporal.scheduling.ConnectionManagerWorkflowImpl.run(ConnectionManagerWorkflowImpl.kt:237) at ConnectionManagerWorkflowImplProxy.run$accessor$m5ozq4Io(Unknown Source) at ConnectionManagerWorkflowImplProxy$auxiliary$XPXAJbk9.call(Unknown Source) at io.airbyte.micronaut.temporal.TemporalActivityStubInterceptor.execute(TemporalActivityStubInterceptor.kt:72) at ConnectionManagerWorkflowImplProxy.run(Unknown Source) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at io.temporal.internal.sync.POJOWorkflowImplementationFactory$POJOWorkflowImplementation$RootWorkflowInboundCallsInterceptor.execute(POJOWorkflowImplementationFactory.java:426) at io.temporal.internal.sync.POJOWorkflowImplementationFactory$POJOWorkflowImplementation.execute(POJOWorkflowImplementationFactory.java:374) at io.temporal.internal.sync.WorkflowExecutionHandler.runWorkflowMethod(WorkflowExecutionHandler.java:71) at io.temporal.internal.sync.SyncWorkflow.lambda$start$0(SyncWorkflow.java:144) at io.temporal.internal.sync.CancellationScopeImpl.run(CancellationScopeImpl.java:103) at io.temporal.internal.sync.WorkflowThreadImpl$RunnableWrapper.run(WorkflowThreadImpl.java:107) at io.temporal.worker.ActiveThreadReportingExecutor.lambda$submit$0(ActiveThreadReportingExecutor.java:54) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583) Caused by: io.temporal.failure.ApplicationFailure: type='java.lang.NullPointerException', nonRetryable=false at java.base/java.util.Objects.requireNonNull(Objects.java:233) at java.base/java.util.ImmutableCollections$Map1.<init>(ImmutableCollections.java:1112) at java.base/java.util.Map.of(Map.java:1365) at io.airbyte.workers.temporal.scheduling.activities.AutoDisableConnectionActivityImpl.autoDisableFailingConnection(AutoDisableConnectionActivityImpl.kt:39) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at io.temporal.internal.activity.RootActivityInboundCallsInterceptor$POJOActivityInboundCallsInterceptor.executeActivity(RootActivityInboundCallsInterceptor.java:64) at io.temporal.internal.activity.RootActivityInboundCallsInterceptor.execute(RootActivityInboundCallsInterceptor.java:43) at io.temporal.internal.activity.ActivityTaskExecutors$BaseActivityTaskExecutor.execute(ActivityTaskExecutors.java:107) at io.temporal.internal.activity.ActivityTaskHandlerImpl.handle(ActivityTaskHandlerImpl.java:124) at io.temporal.internal.worker.ActivityWorker$TaskHandlerImpl.handleActivity(ActivityWorker.java:290) at io.temporal.internal.worker.ActivityWorker$TaskHandlerImpl.handle(ActivityWorker.java:254) at io.temporal.internal.worker.ActivityWorker$TaskHandlerImpl.handle(ActivityWorker.java:217) at io.temporal.internal.worker.PollTaskExecutor.lambda$process$1(PollTaskExecutor.java:96) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583)

The worker log reveals the root cause more clearly. The key error is:

Caused by: io.temporal.failure.ApplicationFailure: type='java.lang.NullPointerException', nonRetryable=false
    at io.airbyte.workers.temporal.scheduling.activities.AutoDisableConnectionActivityImpl.autoDisableFailingConnection(AutoDisableConnectionActivityImpl.kt:39)

The

AutoDisableFailingConnection

activity is throwing a

NullPointerException

inside

AutoDisableConnectionActivityImpl

, which causes it to exhaust all retries (

RETRY_STATE_MAXIMUM_ATTEMPTS_REACHED

). This then causes the

ConnectionManagerWorkflow

to restart after a 10-minute delay — which explains why your sync never starts. The NPE at

java.util.Map.of(Map.java:1365)

/

ImmutableCollections$Map1.<init>

suggests that a null value is being passed into a Map that doesn't allow null values, which is a pattern seen in other Airbyte issues. [connection errors] The knowledge sources do not contain specific information about this exact version of

AutoDisableConnectionActivityImpl

or a confirmed fix for this particular NPE. However, based on similar patterns seen in the knowledge sources (e.g., NPEs in activity implementations being resolved by upgrading Airbyte), here are the recommended steps: 1. Check your Airbyte version and consider upgrading to the latest release, as NPEs in Temporal activity implementations have historically been fixed in newer versions. [intermittent NPE fix] 2. Check if the connection ID is null — the log shows

Connection null failed

, which suggests the connection identifier may not be resolving correctly, possibly pointing to a database or configuration issue. 3. Check your database connectivity from the worker pod, as a failure to retrieve connection metadata could result in null values being passed downstream. I'd recommend opening a GitHub issue or reaching out to Airbyte support with these logs if upgrading doesn't resolve the problem, as the specific NPE in

AutoDisableConnectionActivityImpl

is not covered in the available knowledge sources. 👍 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 i can see this in cron logs 2026-03-23 173531,197 [scheduled-executor-thread-2] ERROR i.m.s.DefaultTaskExceptionHandler(handle):47 - Error invoking scheduled task for bean [io.airbyte.cron.jobs.SelfHealTemporalWorkflows@99b96c] RESOURCE_EXHAUSTED: namespace rate limit exceeded io.grpc.StatusRuntimeException: RESOURCE_EXHAUSTED: namespace rate limit exceeded at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:351) at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:332) at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:174) at io.temporal.api.workflowservice.v1.WorkflowServiceGrpc$WorkflowServiceBlockingStub.listClosedWorkflowExecutions(WorkflowServiceGrpc.java:5903) at io.airbyte.commons.temporal.WorkflowServiceStubsWrapped.blockingStubListClosedWorkflowExecutions$lambda$0(WorkflowServiceStubsWrapped.kt:38) at dev.failsafe.Functions.lambda$toCtxSupplier$11(Functions.java:243) at dev.failsafe.Functions.lambda$get$0(Functions.java:46) at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74) at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187) at dev.failsafe.FailsafeExecutor.call(FailsafeExecutor.java:376) at dev.failsafe.FailsafeExecutor.get(FailsafeExecutor.java:112) at io.airbyte.commons.temporal.RetryHelper.withRetries(RetryHelper.kt:57) at io.airbyte.commons.temporal.WorkflowServiceStubsWrapped.withRetries(WorkflowServiceStubsWrapped.kt:63) at io.airbyte.commons.temporal.WorkflowServiceStubsWrapped.blockingStubListClosedWorkflowExecutions(WorkflowServiceStubsWrapped.kt:37) at io.airbyte.commons.temporal.TemporalClient.fetchClosedWorkflowsByStatus(TemporalClient.kt:137) at io.airbyte.commons.temporal.TemporalClient.restartClosedWorkflowByStatus(TemporalClient.kt:113) at io.airbyte.cron.jobs.SelfHealTemporalWorkflows.cleanTemporal(SelfHealTemporalWorkflows.kt:39) at io.airbyte.cron.jobs.$SelfHealTemporalWorkflows$Definition$Exec.dispatch(Unknown Source) at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invoke(AbstractExecutableMethodsDefinition.java:456) at io.micronaut.inject.DelegatingExecutableMethod.invoke(DelegatingExecutableMethod.java:86) at io.micronaut.context.bind.DefaultExecutableBeanContextBinder$ContextBoundExecutable.invoke(DefaultExecutableBeanContextBinder.java:152) at io.micronaut.scheduling.processor.ScheduledMethodProcessor.lambda$scheduleTask$2(ScheduledMethodProcessor.java:160) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583)

The cron log error is:

RESOURCE_EXHAUSTED: namespace rate limit exceeded

This is a known Airbyte issue. The

SelfHealTemporalWorkflows

cron job is hitting Temporal's namespace rate limit when trying to list closed workflow executions (

listClosedWorkflowExecutions

). This is exactly the same error pattern seen in multiple reported issues. [airbyte services stuck; sync attempt hanging] What this means in your context: Combined with the worker log from your previous message (the

AutoDisableFailingConnection

NPE causing repeated workflow failures and restarts), your Temporal namespace is likely being overwhelmed by the volume of workflow operations — failed syncs retrying, the cron job repeatedly trying to list/restart closed workflows, etc. This creates a feedback loop that exhausts the Temporal rate limit. [airbyte services stuck] What has helped others: 1. Upgrade Airbyte — A fix related to Temporal configuration defaults and the cron job behavior was merged and released in v1.5.0 of the Airbyte platform. The fix included better Temporal defaults and changes to prevent the cron from running aggressively alongside all components. [sync attempt hanging] 2. Increase server resources — In some cases, increasing CPU/memory for the Temporal-related services helped reduce the rate limit pressure. [DEADLINE_EXCEEDED workaround] 3. Address the root NPE first — The

NullPointerException

in

AutoDisableConnectionActivityImpl

(from your worker logs) is causing repeated workflow failures, which in turn drives up Temporal API calls from the cron job. Fixing that underlying issue should reduce the load on Temporal. In summary, the

RESOURCE_EXHAUSTED

error in the cron is a symptom of the broader instability caused by the NPE-driven workflow failure loop. Upgrading Airbyte to a version ≥ 1.5.0 is the most directly supported recommendation from the knowledge sources. 👍 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 in temporal pod logs i can see: {"level":"warn","ts":"2026-03-23T174120.284Z","msg":"Per shard per namespace RPS warn limit exceeded","service":"history","shard-id":4,"wf-namespace":"default","rps":134,"logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/common/persistence/health_signal_aggregator.go:171"} {"level":"warn","ts":"2026-03-23T174120.284Z","msg":"Per shard RPS warn limit exceeded","service":"history","shard-id":4,"rps":134,"logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/common/persistence/health_signal_aggregator.go:178"} {"level":"warn","ts":"2026-03-23T174150.284Z","msg":"Per shard per namespace RPS warn limit exceeded","service":"history","shard-id":4,"wf-namespace":"default","rps":141,"logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/common/persistence/health_signal_aggregator.go:171"} {"level":"warn","ts":"2026-03-23T174150.284Z","msg":"Per shard RPS warn limit exceeded","service":"history","shard-id":4,"rps":141,"logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/common/persistence/health_signal_aggregator.go:178"} {"level":"warn","ts":"2026-03-23T174220.284Z","msg":"Per shard per namespace RPS warn limit exceeded","service":"history","shard-id":4,"wf-namespace":"default","rps":140,"logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/common/persistence/health_signal_aggregator.go:171"} {"level":"warn","ts":"2026-03-23T174220.284Z","msg":"Per shard RPS warn limit exceeded","service":"history","shard-id":4,"rps":140,"logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/common/persistence/health_signal_aggregator.go:178"}

The Temporal pod logs confirm what was already indicated by the cron

RESOURCE_EXHAUSTED

errors. The warnings:

"Per shard per namespace RPS warn limit exceeded" (rps: 134–141)
"Per shard RPS warn limit exceeded" (rps: 134–141)

mean that Temporal's persistence layer (the history service) is receiving more requests per second than its configured shard limits allow. This is the underlying cause of the

RESOURCE_EXHAUSTED: namespace rate limit exceeded

errors you saw in the cron logs. This is a known pattern in Airbyte deployments. The knowledge sources confirm this type of Temporal overload has been observed when: • Too many concurrent syncs are running or retrying, flooding Temporal with workflow operations. [airbyte services stuck] • The NPE-driven failure loop (the

AutoDisableFailingConnection

NullPointerException from your worker logs) causes workflows to repeatedly fail and restart, generating a high volume of Temporal API calls. • The

SelfHealTemporalWorkflows

cron job repeatedly calls

listClosedWorkflowExecutions

, adding further load. [sync attempt hanging] Recommended actions (supported by knowledge sources): 1. Upgrade Airbyte to v1.5.0 or later — a fix was merged that improved Temporal configuration defaults and reduced aggressive cron behavior, which directly addresses this type of rate limit exhaustion. [sync attempt hanging] 2. Reduce concurrent syncs — temporarily pause non-critical connections to reduce the load on Temporal. [sync pulling 0 records] 3. Increase Temporal pod resources (CPU/memory) — resource pressure on the Temporal pod can contribute to RPS limit breaches. [Salesforce connections stuck] 4. Fix the root NPE in

AutoDisableConnectionActivityImpl

— this is the primary driver of the workflow failure loop that is generating excessive Temporal traffic. All three log sources (server, worker, cron, and now Temporal pod) are pointing to the same cascading issue rooted in the NPE causing repeated workflow failures. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.