[API] Timeout error has occurred when creating connection by terraform #29506
Comments
Saku3449
added
area/connectors
terraform {
required_providers {
airbyte = {
source = "airbytehq/airbyte"
version = "0.3.1"
}
}
}
provider "airbyte" {
username = MY_USER_NAME
password = MY_PASSWORD
server_url = "http://localhost:8006/v1"
}
resource "airbyte_workspace" "my_workspace" {
name = MY_WORKSPACE_NAME
}
resource "airbyte_source_exchange_rates" "exchangerates" {
configuration = {
access_key = MY_ACCESS_KEY
ignore_weekends = true
source_type = "exchange-rates"
start_date = "2023-04-01"
}
name = "Exchange Rates API"
workspace_id = airbyte_workspace.my_workspace.workspace_id
}
resource "airbyte_destination_bigquery" "bigquery" {
configuration = {
big_query_client_buffer_size_mb = 15
credentials_json = file("./credentials.json")
dataset_id = MY_DATASET_ID
dataset_location = "asia-northeast1"
destination_type = "bigquery"
loading_method = {
destination_bigquery_loading_method_standard_inserts = {
method = "Standard"
}
}
project_id = MY_PROJECT_ID
transformation_priority = "batch"
}
name = "BigQuery"
workspace_id = airbyte_workspace.my_workspace.workspace_id
}
resource "airbyte_connection" "exchangerates_bigquery" {
configurations = {
streams = [
{
cursor_field = [
"date",
]
name = "exchange_rates"
sync_mode = "full_refresh_overwrite"
},
]
}
data_residency = "auto"
destination_id = airbyte_destination_bigquery.bigquery.destination_id
name = "Exchangerates to BigQuery"
namespace_definition = "destination"
non_breaking_schema_updates_behavior = "ignore"
schedule = {
schedule_type = "manual"
}
source_id = airbyte_source_exchange_rates.exchangerates.source_id
status = "active"
} |
|
I think I am facing the same issue, whilst I am not using the Terraform Provider, but rather the Airbyte API directly. |
|
I am facing the same problem when I try to do a count or for_loop to create multiple database resources using terraform. |
|
Setting -parallelism=1 during any terraform cli calls seems to have helped with this issue. |
|
I believe there's an issue with the Airbyte API Server's Read Timeout setting. |
|
I am also facing the same issue when I'm trying to create an |
|
Same here with the API! |
|
I'm also facing this issue, both via terraform and API. |
|
Also facing this issue on version 0.50.22 via the airbyte API. |
|
I have this issue with the api-server :( |
|
Also, facing the same issue. |
|
I am having the same issue using the /v1/connections endpoint :( |
|
Are any other API endpoints working for you? I'm wondering if this is related? #30107 I'm wondering if this has something to do with trackSuccess function not seeing the success message back from airbyte-server? I see some log4j error messages during init. I saw a recent change where the 20s timeout was increased but now it just takes longer to timeout whenever I call the api. I think the new timeout was 150s or something. I can't find the commit right now. |
Thank you, I'll try it later.
This one? |
|
Looks like you can set your own now in 0.50.29 |
|
@chreds, even if we increase the timeout it just makes the timeout error to come on a longer response time. |
|
@ashutosh-015 Yes that's my experience here too. |
|
@chreds Any luck in making this work? |
|
We upgraded airbyte helm chart to 0.49.1 and it seems like we we're previously getting a 20s timeout on the api server, to now getting a client-side terraform timeout of 60s (Client.Timeout exceeded while awaiting headers). I'm guessing it's this https://github.com/airbytehq/terraform-provider-airbyte/blob/6e55dd87be8c72bb7b6311783f79f3027b9ab20c/internal/sdk/sdk.go#L135 in airbyte provider that sets it for all airbyte resources |
No. Hoping someone else can help. This is blocking me right now. |
|
We're experiencing the same issue on multiple Airbyte versions, all deployed in Kubernetes with the helm chart. We've tested from chart version 0.48.2 to 0.49.1, all with the same behavior. |
|
Same here, any luck anyone with this? |
|
Running into the same issue. Running Airbyte on k8s using the helm chart. I am able to reproduce the problem with a simple CURL request to |
|
This is completely blocking our company pipelines! @marcosmarxm anything we can help? It seems that many users are facing this problem. Any timeframe to fix this issue? |
|
We are also experiencing this issue. As @chreds says:
Even if I were able to increase the hardcoded Terraform timeout, as commented by @erik-gustafsson-vargas:
I still don't think this would solve the issue as it's the server that's timing out. |
|
Guys, this is frustrating. I have raised this on Office hours as well. Now they have even stopped office hours. I have no idea where to expect a response or what? Any luck ? |
|
Hello 👋 sorry for the missing reply here. I asked one of Airbyte engineers to take a look and return about what can be done here. |
|
Hey all, this should be resolved as of https://github.com/airbytehq/airbyte-platform/releases/tag/v0.50.31. That release both includes some increased default timeouts as well as a change to how our micronaut server allocates threads in order to avoid timing out. Please let us know if timeout issues persist on the new version. |
|
I can confirm this is working here for me now. For anyone with modifications to your docker-compose.yaml or .env files, make sure you merge in changes for .env and docker-compose.yaml, in particular there's a new INTERNAL_API_URL environment variable in .env and that gets referenced in the airbyte-api-server docker config now. |
|
This isn't working for me using the 0.49.5 helm chart. I suspect it might be related to the change to the @chreds mentioned Edit: Confirmed. Adding |
|
I'm not sure if INTERNAL_API_HOST is still used by something else (without the http://). I'm guessing it is since they created a new env variable instead (INTERNAL_API_URL). So probably something else in the helm chart needs to be updated to reference that new variable INTERNAL_API_URL and then the env config needs that added. |
Yes, I agree. I opened a PR using the same approach. |
|
I'm using helm deployment for running Airbyte and in previous versions I've been facing the timeout issue. In the newest helm chart (0.49.4) where Airbyte v0.50.31 is used the issue have changed and currently the micronaut error: Do you have any ideas how to solve this issue? P.S. The health check returns |
|
@storytel-siudzinskim It looks like you haven't made the changes needed for the new environment variable. You should try the PR @a-monteiro made above or wait for it to be merged in. |
Any news on this? |
|
Hi @JonsSpaghetti |
|
Hi ! In our case we just added in env_vars:
INTERNAL_API_HOST: http://airbyte-airbyte-server-svc:8001(here {{ .Release.Name }} is "airbyte") To make it work while we wait for the PR to be merged 👍 |
|
Thank you @aballiet , it works. The default value We need to re-install the chart, seems it doesn't allow to patch directly the env. |
|
There is a similar issue that is already fixed. Probably the fix also handles this issue as well. |
|
Hi!! One important detail here is that all endpoint, in my case, were working except when I was trying to create a connection. I was able to solve it upgrading airbyte to version 0.50.44. Hope any of you find this useful. |
marcosmarxm
changed the title
marcosmarxm
added
team/compose
area/terraform-sdk
and removed
area/connectors
|
Closing as duplicate, but let us know if there are still issues here and we can re-open if needed |
and others
Connector Name
source-ExchangeRateAPI, destination-BigQuery
Connector Version
0.3.1
What step the error happened?
Configuring a new connector
Revelant information
I have tried to establish a connection using terraform to code a configuration for AirByte that works locally.
The source is ExchangeRateAPI and the destination is BigQuery.
When I tried to create a connection using this code, I got this error
The docker log at this time is as follows
To solve this problem, I thought it would be better to extend the read-timeout here, so I downloaded AirByte-API-Server and changed it to use the Image created from its Dockerfile.
However, the timeout error occurred in the same number of seconds.
Please make it possible to adjust the timeout for connection creation.
Relevant log output
No response
Contribute
The text was updated successfully, but these errors were encountered: