@kapa.ai seeing this

Id not found exception [errorId: 535e869d-a │
│ b3-44ad-b461-6540b7f11df3[]: class NotFoundKnownExceptionInfo {                                                                                             │
│     id: 633_0                                                                                                                                               │
│     message: Could not find attempt stats for job_id: 633 and attempt no: 0                                                                                 │
│     exceptionClassName: io.airbyte.commons.server.errors.IdNotFoundKnownException                                                                           │
│     exceptionStack: [io.airbyte.commons.server.errors.IdNotFoundKnownException: Could not find attempt stats for job_id: 633 and attempt no: 0,     at io.a │
│ irbyte.commons.server.handlers.AttemptHandler.getAttemptCombinedStats(AttemptHandler.kt:254),     at io.airbyte.server.apis.controllers.AttemptApiControlle │
│ r.getAttemptCombinedStats$lambda$0(AttemptApiController.kt:66),     at io.airbyte.server.apis.ApiHelper.execute(ApiHelper.kt:33),     at io.airbyte.server. │
│ apis.controllers.AttemptApiController.getAttemptCombinedStats(AttemptApiController.kt:65),     at io.airbyte.server.apis.controllers.$AttemptApiController$ │
│ Definition$Exec.dispatch(Unknown Source),     at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invokeUnsafe(AbstractE │
│ xecutableMethodsDefinition.java:461),     at io.micronaut.context.DefaultBeanContext$BeanContextUnsafeExecutionHandle.invokeUnsafe(DefaultBeanContext.java: │
│ 4454),     at io.micronaut.web.router.AbstractRouteMatch.execute(AbstractRouteMatch.java:272),     at io.micronaut.web.router.DefaultUriRouteMatch.execute( │
│ DefaultUriRouteMatch.java:38),     at io.micronaut.http.server.RouteExecutor.executeRouteAndConvertBody(RouteExecutor.java:466),     at io.micronaut.http.s │
│ erver.RouteExecutor.lambda$callRoute$5(RouteExecutor.java:443),     at io.micronaut.core.execution.ExecutionFlow.lambda$async$0(ExecutionFlow.java:92),     │
│  at io.micronaut.core.propagation.PropagatedContext.lambda$wrap$3(PropagatedContext.java:232),     at java.base/java.util.concurrent.ThreadPoolExecutor.run │
│ Worker(ThreadPoolExecutor.java:1144),     at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642),     at java.base/ja │
│ va.lang.Thread.run(Thread.java:1583), ]                                                                                                                     │
│     rootCauseExceptionClassName: null                                                                                                                       │
│     rootCauseExceptionStack: []                                                                                                                             │
│     errorId: ad7aa4cc-63e0-4856-a164-68bdd4c8c396                                                                                                           │
│

after moving to airbyte v2. We have external db as RDS help let me know if you need any other context

Thinking completed I'm sorry, but the provided knowledge sources do not contain enough information to provide an exact fix or root cause for this specific

IdNotFoundKnownException: Could not find attempt stats for job_id: <id> and attempt no: <no>

exception. However, based on related issues in the provided documents, here is what is known about this behavior: 1. What the Error Means • This occurs when the Airbyte Server (specifically

AttemptHandler.getAttemptCombinedStats

/

JobHistoryHandler

) queries the persistence layer for attempt statistics for an attempt that has no recorded stats [forum post]. • It frequently happens when: ◦ An attempt failed, crashed, or was terminated early before emitting/persisting any synchronization metrics [github issue]. ◦ The UI or an API call requests job/attempt history while an attempt is still initializing, hanging, or in a pending/failed state where stats were never populated [github issue]. ◦ In many cases, these "missing stats" log entries act as warnings and indicate polling noise rather than a fatal crash of the server itself [forum post]. 2. Common Causes After Moving to Helm Chart V2 / Airbyte 2.x When migrating to Chart V2 or 2.x with an external PostgreSQL RDS database: • Database migrations or connection states: Database schema migrations run via the bootloader on the external database during upgrade [github issue]. If older jobs were in-flight during the migration, their attempt records might lack final statistics. • Workload launcher authentication issues: Post-upgrade migrations can sometimes cause worker or workload-launcher authentication issues (e.g., 401/500 errors talking to the server API), leading to attempts failing immediately without recording stats [github issue]. Next Steps to Investigate To help isolate the issue, it would be useful to check: 1. Sync status: Is the sync job (job

633

) actively failing, or is it completing successfully while this error simply pollutes your server logs? 2. Worker / Orchestrator logs: Check the logs for the worker, orchestrator, or workload-launcher pods corresponding to job

633

attempt

0

to see why the attempt terminated without recording statistics. 3. Bootloader logs: Verify that the

airbyte-bootloader

completed all database migrations successfully without failing or skipping on your RDS instance [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.

1. @kapa.ai Sync status: Is the sync job (job

633

) actively failing, or is it completing successfully while this error simply pollutes your server logs? the sync does not start the error was caught in the server po

Thinking completed I'm sorry, but the provided knowledge sources do not explicitly explain why that exact

Could not find attempt stats

exception is thrown before a sync starts. However, based on the documented issues regarding syncs that fail to start or hang in "Queued" status after upgrading to Airbyte 2.x / Helm Chart V2, the missing attempt stats are typically a downstream symptom of the job never actually being claimed or executed by the workload runner [github issue]. When a sync does not start, the server attempts to retrieve stats for an attempt (

attempt no: 0

) that never initialized or never reached an executor. Here are the primary causes documented after upgrading to 2.x: 1. Dataplane Group Mismatch (Workload Never Claimed) When upgrading from 1.x to 2.0.x, the

airbyte-bootloader

often creates a new

dataplane_group

record in the database instead of reusing the existing one [github issue]. • Symptoms: Syncs remain stuck in "Queued", fail immediately, or timeout with

The workload was never claimed

[github issue]. • The Cause: The

workload-launcher

registers under the new dataplane group ID, while sync workloads continue to route to the old group ID in the database [github issue]. Because the launcher never claims the pending workload, no attempt is ever started, leading to missing stats [github issue]. • How to verify: Inspect your database:-- Check the dataplane_group assigned to pending workloads: SELECT id, status, dataplane_group FROM workload WHERE status = 'pending'; -- Check the dataplane_group assigned to active dataplanes: SELECT d.id, d.dataplane_group_id, dg.name FROM dataplane d JOIN dataplane_group dg ON dg.id = d.dataplane_group_id WHERE d.tombstone = false;If these IDs do not match, the launcher cannot poll or claim the workloads [github issue]. 2. Bootloader Migration or Missing Workspace Configurations After an upgrade, database migrations may fail to link existing workspaces or configurations properly: • In large version jumps to 2.x, the server may fail to look up configuration for the workspace or connection (e.g., throwing

STANDARD_WORKSPACE

not found or

workspaceId: null

), which prevents the workflow from dispatching [github issue]. • Check: Review the

airbyte-bootloader

logs to ensure all database migrations ran and completed successfully against your external RDS instance [github issue]. 3. Check workload-launcher Logs Look at the logs for the

airbyte-workload-launcher

pod: • If healthy and polling, you should see:Resuming ApiQueuePoller with group-id and high Resuming ApiQueuePoller with group-id and default • If it is only executing

PodSweeper

cycles and not claiming workloads, it is likely affected by the dataplane group mismatch or missing runner registration [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.