Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

object comparison failed #228

Open
celeronsx opened this issue Feb 28, 2025 · 4 comments
Open

object comparison failed #228

celeronsx opened this issue Feb 28, 2025 · 4 comments
Labels
bug Something isn't working

Comments

@celeronsx
Copy link

The embedded_client feature works great but has has several concerns.
From time to time i get this error:

module.bitwarden["redis-backend-persistence"].bitwarden_item_login.bitwarden_logins["skeleton_service"]: Creating...
╷
│ Error: object comparison failed
│ 
│   with module.bitwarden["redis-backend-persistence"].bitwarden_item_login.bitwarden_logins["skeleton_service"],
│   on ../../../modules/bitwarden/main.tf line 1, in resource "bitwarden_item_login" "bitwarden_logins":
│    1: resource "bitwarden_item_login" "bitwarden_logins" {
│ 
╵

What does it mean and how I can solve it?

@maxlaverse maxlaverse added the bug Something isn't working label Feb 28, 2025
@maxlaverse
Copy link
Owner

Hi @celeronsx !
Thanks for reporting this issue. Indeed, the message is not helpful at all.

It was meant as a safety measure but has actually two different purposes:

  1. Make sure that the objects we encrypt can be decrypted and return an identical value. If that's not the case, we should absolutely fail.
  2. Detect inconsistencies in server responses. With official Bitwarden servers, it happens that the object returned after the creation or edition, is different than when we fetch it again afterwards. The idea was to make a list of those inconsistencies so we we can spare this extra re-fetch after creation objects which has performance limitations (because of API throttling).

I've released v0.13.3 which improves the error message by displaying the fields that are different. Eventually, I'll add a flag to ignore such errors and if they're not coming from encryption verification.

If you have time, could you try out this new version and paste the additional information here ? There is an issue with Terraform's registry currently, that prevents me from updating the key used for signing releases. Concretely, it means you can't just run terraform init -upgrade to get the newest release. OpenTofu works fine.

Are you using Bitwarden.com or did this happened with a self-hosted version ?

@celeronsx
Copy link
Author

It is a self-hosted version. I have been using your provider for a long time and remember when we had many issues before your great new option, embedded_client, was introduced.

We have a self-hosted Bitwarden server (version 2024.12.1) and are using Terraform version 1.7.5 (with provider version 1.13.0). Today, I will upgrade to the latest version.

However, how can I do it? I can’t find the latest version here: https://registry.terraform.io/providers/maxlaverse/bitwarden/latest/docs. Perhaps we need to run a GitHub Action to release it?

Yes, one more point: when this error occurs, the object is indeed created, but it is not added to the state. Consequently, it is created again in the next plan, requiring manual cleanup.

@maxlaverse
Copy link
Owner

Thanks for the additional information.

v0.13.3 is actually released, it's really just Terraform's Registry not picking it up. I already opened a ticket to support, but since I'm not a company, they don't guarantee any reply.

The way I install versions by hand outside of the registry is hacky, not practical if multiple persons have to do it. You would need to:

  1. Download the release for your platform here: https://github.com/maxlaverse/terraform-provider-bitwarden/releases/tag/v0.13.3
  2. Look into the .terraform folder of your workspace and find the location of the provider for the currently installed version
  3. Replaced it with the version you downloaded
  4. Modify .terraform.lock.hcl to remove the hashes section of that provider.

I'll work on a new version, if I can this week-end, which disables the check, but Terraform users would have to wait for this registry issues to be solved anyway. If I don't hear from them in a week, I would try a different solution.

@maxlaverse
Copy link
Owner

@celeronsx actually for now there is a much easier workaround to access the latest version, which is to explicitly refer to the OpenTofu registry despite using terraform and not tofu:

Instead of:

terraform {
  required_providers {
    bitwarden = {
      source  = "maxlaverse/bitwarden"
      version = ">= 0.13.3"
    }
  }
}

Use:

terraform {
  required_providers {
    bitwarden = {
      source  = "registry.opentofu.org/maxlaverse/bitwarden"
      version = ">= 0.13.3"
    }
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants