Database item throws error on apply

[codezninja]

Your environment

Terraform Provider Version: 2.1.2

Connect Server Version: 1.7.3

CLI Version: N/A

OS: alpine (running on hashicorp/terraform:1.11.1 docker image)

Terraform Version: 1.11.1

What happened?

Item category database no longer accepts an empty string for database to successfully on apply. The statefile saves and the item is created but terraform throws an error. This is a problem cause ci/cd fails

Initializing the backend...
Initializing provider plugins...
- Reusing previous version of 1password/onepassword from the dependency lock file
- Using previously-installed 1password/onepassword v2.1.2

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # onepassword_item.test will be created
  + resource "onepassword_item" "test" {
      + category = "database"
      + id       = (known after apply)
      + password = (sensitive value)
      + port     = "3306"
      + title    = "Database Test"
      + username = "hello"
      + uuid     = (known after apply)
      + vault    = "xxxxxxxxxx"
        # (1 unchanged attribute hidden)
    }

Plan: 1 to add, 0 to change, 0 to destroy.
onepassword_item.test: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to onepassword_item.test, provider "provider[\"registry.terraform.io/1password/onepassword\"]" produced an unexpected new value:
│ .database: was cty.StringVal(""), but now null.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

What did you expect to happen?

Like 1x provider version I accept a successful apply with no errors

Steps to reproduce

1. https://github.com/codezninja/1p-test/tree/main
2. cd to common dir and create a default.auto.tfvars with vault_id and connect server url variables

op_url   = "https://url.to-op-connect.com"
vault_id = "xxxxxxxx"

3. cd back to root and run the run.sh

cd ../ && ./run.sh

Notes & Logs