Unexpected behavior during terraform apply step with fivetran_connector resource

[loeakaodas]

Describe the bug
When attempting to run a terraform apply the below error is produced. No issues flagged when running terraform plan.

fivetran_connector.tf_test_connector: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to fivetran_connector.tf_test_connector, provider "provider[\"registry.terraform.io/fivetran/fivetran\"]" produced an unexpected new value: .config.api_version: was
│ cty.StringVal("random_value"), but now null.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

To Reproduce
Below is the resource block that is causing the issue. The config in this case intentionally has an extra value api_version as I'm testing how this would work if these k/v are provided by users and aren't validated. Running terraform apply with the latest version and example config causes the error.

resource "fivetran_connector" "tf_test_connector" {
  group_id        = fivetran_group.my_destination.id
  service         = "fivetran_log"
  run_setup_tests = true

  destination_schema {
    name = "tf_test_connector"
  }

  config {
    is_account_level_connector = "false"
    api_version                = "random_value"
  }

  timeouts {
    create = "60m"
    update = "60m"
  }

  depends_on = [
    fivetran_destination.my_destination
  ]
}

Expected behavior
I would expect that the connector config would be validated during the plan step and throw an error

Logs & Output
Provide terraform CLI output on plan | apply. If it is possible, please, refer to this guide to enable debug output.

Attached logs of [partial] plan and full apply steps:
tf_plan_log.txt
tf_apply_log.txt

Plugin version:
Using the latest provider version of 1.3.2

Additional context
I believe this is happening because the provider is patching the config fields here...possibly

[fivetran-jovanmanojlovic]

The api_version is not expected for fivetran_log.

[loeakaodas]

@fivetran-jovanmanojlovic yes, I am aware of that and would expect the provider throw an error during the plan step instead of the apply step. Because it actually creates the connector and throws an error

[rohitmsaxena]

@loeakaodas Were you able to find a workaround? I am also not sure why this is an enhancement when this makes the connector useless.

[loeakaodas]

@loeakaodas Were you able to find a workaround? I am also not sure why this is an enhancement when this makes the connector useless.

@rohitmsaxena No, I do not have a workaround.

For my use case I could probably validate the inputs before they get to the provider with the OpenAPI spec or just write custom code to call the APIs directly, but this would add an additional maintenance burden for my project. This has delayed a POC I've been working on for over a year (#219) and as a result it's been deprioritized.