Troubleshooting Airbyte Server Pod Errors after Migration to abctl

Summary

After migrating from a docker-compose deployment to an abctl-based one, encountering errors in the Airbyte server pod related to S3 bucket and job ID not found. Additionally, facing HTTP 500 error when visualizing logs from connections. Seeking assistance on resolving these issues.


Question

Hello everyone!
With my colleague <@U05FB419LMR>, we are attempting to migrate from a docker composer based airbyte deployment to an abctl based one. We have advanced quite a lot since our last issue https://airbytehq.slack.com/archives/C021JANJ6TY/p1727866852503529|here. We currently have the airbyte abctl deployed 0.63.20 version of airbyte, “migrated” from a docker composed deployed version following your documentation https://docs.airbyte.com/using-airbyte/getting-started/oss-quickstart#migrating-from-docker-compose-optional|here. We have deployed a Cloud SQL proxy in parellel to the abctl as a service pod pair. If anyone in a GCP based environment is having problems with this they can contact us as we have the connection with the db working well. :wobble-dance-party:

What is still not 100% though is our airbyte server pod. Even though, the UI is working fine and I am seeing my sources, destinations and connectors from our previous docker composer deployment, the server pod is demonstrating these error logs such as these:

software.amazon.awssdk.services.s3.model.NoSuchBucketException: The specified bucket does not exist (Service: S3, Status Code: 404, Request ID: 1807DEAEFA0A16B0, Extended Request ID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8)```
And
```2024-11-14 15:17:08 ERROR i.a.s.a.ApiHelper(execute):49 - Unexpected Exception
io.airbyte.commons.server.errors.IdNotFoundKnownException: Could not find attempt stats for job_id: 4 and attempt no: 0```
as well as:
```2024-11-14 15:17:08 ERROR i.a.c.s.e.h.IdNotFoundExceptionHandler(handle):33 - Not found exception class NotFoundKnownExceptionInfo {
    id: null
    message: Id not found: Could not find attempt stats for job_id: 4 and attempt no: 0
    exceptionClassName: io.airbyte.commons.server.errors.IdNotFoundKnownException```
Has anyone encountered these errors when migrating from docker compose or deploying airbyte with abctl?

Another information that might be interesting to share is that if I try to visualise logs from connections that ran in the previous docker compose environment, I gett a HTTP 500 error on airbyte UI with the following stack trace:
```{
  "url": "<http://localhost:8000/workspaces/0afed4c6-deab-4352-bb00-0bfc4fcdaf85/connections/d4203252-2d41-492f-aaad-7333f186e1db/job-history>",
  "airbyteVersion": "0.63.20",
  "errorType": "HttpError",
  "errorConstructor": "bd",
  "error": {
    "i18nKey": "errors.http.internalServerError",
    "i18nParams": {
      "status": 500
    },
    "name": "HttpError",
    "requestId": "aaLMA5ccFf3zpVhzL6nCYj",
    "request": {
      "url": "/api/v1/attempt/get_for_job",
      "method": "post",
      "headers": {
        "Content-Type": "application/json"
      },
      "data": {
        "jobId": 1,
        "attemptNumber": 0
      }
    },
    "status": 500,
    "response": {
      "message": "Internal Server Error: The specified bucket does not exist (Service: S3, Status Code: 404, Request ID: 1807DEBD2A1F4AB0, Extended Request ID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8)",
      "exceptionClassName": "software.amazon.awssdk.services.s3.model.NoSuchBucketException",
      "exceptionStack": [
        "software.amazon.awssdk.services.s3.model.NoSuchBucketException: The specified bucket does not exist (Service: S3, Status Code: 404, Request ID: 1807DEBD2A1F4AB0, Extended Request ID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8)",
        "\tat software.amazon.awssdk.protocols.xml.internal.unmarshall.AwsXmlPredicatedResponseHandler.handleErrorResponse(AwsXmlPredicatedResponseHandler.java:156)",
        "\tat software.amazon.awssdk.protocols.xml.internal.unmarshall.AwsXmlPredicatedResponseHandler.handleResponse(AwsXmlPredicatedResponseHandler.java:108)",
        "\tat software.amazon.awssdk.protocols.xml.internal.unmarshall.AwsXmlPredicatedResponseHandler.handle(AwsXmlPredicatedResponseHandler.java:85)",
        "\tat software.amazon.awssdk.protocols.xml.internal.unmarshall.AwsXmlPredicatedResponseHandler.handle(AwsXmlPredicatedResponseHandler.java:43)",
.....
      ],
      "rootCauseExceptionStack": []
    }
  },
  "stacktrace": "HttpError: errors.http.internalServerError\n    at zve (<http://localhost:8000/assets/core-ku7y43c64a.js:119:10572>)",
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36",
  "featureFlags": {}
}```
Seem to be related with the s3 bucket error on the airbyte server logs?

<br>

---

This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. [Click here](https://airbytehq.slack.com/archives/C021JANJ6TY/p1731599582195379) if you want 
to access the original thread.

[Join the conversation on Slack](https://slack.airbyte.com)

<sub>
["migration", "abctl", "docker-compose", "airbyte-server", "error-logs", "s3-bucket", "job-id", "HTTP-500"]
</sub>

Where did you store your logs in docker-compose setup and where do you want them now?
Exception is about S3, but it might be also related to minio.

The other idea. I’d check Airbyte’s database. Maybe it will be just fine to remove all the attempts, synchronizations history and just keep connections’ states? Before doing anything in database, make a backup.

Hello <@U05JENRCF7C>, you were absolutely right. The issue was related to the logs of the instance. We solved it by following your documentation here: https://docs.airbyte.com/deploying-airbyte/integrations/storage for GCS.
:attention: There is just one small error in your documentation. You name the secret airbyte-config-secrets when for the logs in GCS, airbyte looks for a secret named airbyte-abctl-gcs-log-creds . Changing the name of the secret to airbyte-abctl-gcs-log-creds solves the issue and we successfully managed to migrate our docker compose deployment in a GCP VM + Cloud SQL instance!