@kapa.ai: commands will detect it and remind you to do so if necessary. ╷ │ Warning: Deprecated │ │ with airbyte_source_mongodb_v2.mongodb_source_v2, │ on main.tf line 192, in resource "airbyte_source_mongodb_v2" "mongodb_source_v2": │ 192: resource "airbyte_source_mongodb_v2" "mongodb_source_v2" { │ │ This resource is deprecated and will be removed in v1.1. Use airbyte_source │ instead (with airbyte_connector_configuration for optional config │ validation). See the v1 migration guide: │ https://registry.terraform.io/providers/airbytehq/airbyte/latest/docs/guides/v1_migration_guide │ │ (and one more similar warning elsewhere) ╵ ╷ │ Error: Invalid Attribute Value Match │ │ with airbyte_source_mongodb_v2.mongodb_source_v2, │ on main.tf line 192, in resource "airbyte_source_mongodb_v2" "mongodb_source_v2": │ 192: resource "airbyte_source_mongodb_v2" "mongodb_source_v2" { │ │ Attribute configuration.invalid_cdc_cursor_position_behavior value must be │ one of: ["Fail sync" "Re-sync data"], got: "Fail Sync"

You have two issues to address: 1. Fix the Immediate Error The

invalid_cdc_cursor_position_behavior

value is case-sensitive. You used

"Fail Sync"

but the valid values are

"Fail sync"

and

"Re-sync data"

(note the lowercase "s" in "sync"). [MongoDB v2 resource] Change:

invalid_cdc_cursor_position_behavior = "Fail Sync"

To:

invalid_cdc_cursor_position_behavior = "Fail sync"

2. Address the Deprecation Warning The

airbyte_source_mongodb_v2

resource is deprecated and will be removed in provider v1.1. You should migrate to the generic

airbyte_source

resource. [v1 migration guide] Here's how to migrate using the recommended approach with

airbyte_connector_configuration

and a

moved

block (requires Terraform >= 1.8):

data "airbyte_connector_configuration" "mongodb_config" {
  connector_name = "source-mongodb-v2"

  configuration = {
    database_config = {
      self_managed_replica_set = {
        connection_string = "mongodb://example1.host.com:27017,..."
        databases         = ["your_database"]
        auth_source       = "admin"
        schema_enforced   = false
      }
    }
    discover_sample_size                 = 10000
    discover_timeout_seconds             = 600
    initial_load_timeout_hours           = 8
    initial_waiting_seconds              = 300
    invalid_cdc_cursor_position_behavior = "Fail sync"
    queue_size                           = 10000
    update_capture_mode                  = "Lookup"
  }

  configuration_secrets = {
    username = var.mongodb_username
    password = var.mongodb_password
  }
}

resource "airbyte_source" "mongodb_source_v2" {
  name          = "...my_name..."
  workspace_id  = var.workspace_id
  definition_id = data.airbyte_connector_configuration.mongodb_config.definition_id
  configuration = data.airbyte_connector_configuration.mongodb_config.configuration_json
}

# Prevents Terraform from destroying and recreating the existing resource
moved {
  from = airbyte_source_mongodb_v2.mongodb_source_v2
  to   = airbyte_source.mongodb_source_v2
}

The

moved

block tells Terraform to preserve the existing state rather than delete and recreate the resource. Once the migration is complete and applied successfully, you can remove the

moved

block. [migration walkthrough] 👍 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: Does this caused by misconfigured service token or improper annoations in terraform job which is a Kubernetes job?

Based on the conversation history, the errors you encountered were: 1. A deprecation warning about

airbyte_source_mongodb_v2

2. A validation error about an invalid

invalid_cdc_cursor_position_behavior

value (

"Fail Sync"

instead of

"Fail sync"

) Neither of these errors is caused by a misconfigured service token or improper Kubernetes job annotations. They are purely Terraform provider-level issues: • The deprecation warning is because the typed resource

airbyte_source_mongodb_v2

is being phased out in favor of the generic

airbyte_source

resource. [v1 migration guide] • The validation error is a simple case-sensitivity mismatch in the attribute value. [MongoDB v2 resource] That said, the knowledge sources do mention a separate, unrelated issue where Kubernetes deployments can fail due to mismatched

WORKLOAD_API_BEARER_TOKEN

values between the Worker and Workload API Server pods, resulting in HTTP 401/502 errors. [source-postgres issue] However, this is a different problem from what you were experiencing in your Terraform configuration. If you are seeing a different error related to Kubernetes service tokens or annotations, please share the specific error message so I can better assist you. 👍 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: airbyte terraform-provider >=0.13.0 and hashicorp/http - 3.4.0

The knowledge sources do not contain enough information to answer a question specifically about compatibility or usage between the Airbyte Terraform provider > =0.13.0 and hashicorp/http 3.4.0. What the knowledge sources do confirm is: • Provider version 0.13.0 uses the older typed resources (e.g.,

airbyte_destination_custom

), which are now deprecated as of provider 1.0. [v1 migration guide] • The current recommended approach is to use provider ~> 1.0 with the generic

airbyte_source

/

airbyte_destination

resources and the

airbyte_connector_configuration

data source. [Getting Started] Could you clarify what you're trying to achieve? For example: • Are you trying to use

hashicorp/http

alongside the Airbyte provider to fetch data? • Are you seeing a specific error combining these two providers? With more context, I can better assist you based on the available information. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

airbyte terraform-provider >=0.13.0 and hashicorp/http> 3.4.0

Could you provide a bit more detail about what you're trying to do? For example: • Are you using

hashicorp/http

to fetch secrets or configuration data and pass them into the Airbyte Terraform provider? • Are you seeing a specific error when combining these two providers? The knowledge sources I have available don't contain specific information about integrating

hashicorp/http 3.4.0

with the Airbyte Terraform provider, so I'm not able to give a confident answer without knowing more about your use case. What I can confirm from the knowledge sources is that for managing sensitive credentials in the Airbyte Terraform provider, the recommended approach is to use Terraform variables marked as

sensitive = true

and populate them via environment variables (

TF_VAR_*

), a

terraform.tfvars

file, or your preferred secrets management method — rather than hardcoding them. [Getting Started] Please share more details or the specific error you're encountering so I can help further. 👍 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: error sending request: Post │ "http://airbyte-server-svc:8001/api/public/v1/workspaces/9c681f92-dc82-4e35-aa4c-47353d4721ad/definitions/sources": │ EOF

This error is directly related to a known issue documented in the Airbyte GitHub issues. The

EOF

/ empty reply error when calling the `/api/public/v1/workspaces/`WORKSPACE_ID`/definitions/sources` endpoint is a recognized problem in Airbyte OSS deployments on Kubernetes. What's Happening The error occurs because when the API tries to create a custom source definition, it spins up a connector pod to fetch the spec, but that pod fails to communicate back to the server — resulting in the request hanging and eventually returning an

EOF

. The root cause is an internal auth/token connectivity issue between worker pods and the control-plane server. [GitHub issue] Specifically, the connector pod logs show:

Failed to obtain or add access token
java.net.ConnectException: Failed to connect to airbyte-airbyte-server-svc/...:8001

And the server logs show:

java.lang.IllegalStateException: Get Spec job failed.

Known Workarounds Based on the knowledge sources, the following have been noted: 1. Use the UI to create the custom source definition manually — this still works even when the API endpoint fails. [GitHub issue] 2. Use the legacy endpoint

/api/v1/source_definitions/create_custom

— this was reported to still work as a fallback. [GitHub issue] 3. Check your ingress configuration — the issue notes mention that a migration to v1.7 required an ingress update (which may affect connector builder and related functionality). If your ingress hasn't been updated, that could be the root cause. [GitHub issue] Important Note This issue is still open in the Airbyte GitHub repository with no confirmed fix documented in the knowledge sources. If none of the workarounds resolve your issue, I'd recommend commenting on or following the GitHub issue for updates. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.