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

panic: gob: registering duplicate types for "*tfdiags.rpcFriendlyDiag" #268

LorbusChris opened this issue Dec 4, 2019 · 4 comments
bug Something isn't working


Copy link

LorbusChris commented Dec 4, 2019

SDK version

  "Path": "",
  "Version": "v1.3.0"

Description of Problem

In we have multiple plugins for different providers.
Some of those providers have migrated to terraform-plugin-sdk while others haven't and still use terraform.

Over in openshift/installer#2745 I'm bumping these providers, and that's where I run into a problem:

panic: gob: registering duplicate types for "*tfdiags.rpcFriendlyDiag": *tfdiags.rpcFriendlyDiag != *tfdiags.rpcFriendlyDiag

The initialization of them happens here, respectively:

Since they are the same type, just from different vendored files, they can't both be initialized at the same time.

This happens in all runs of our unit as well as e2e tests. Links to exemplary CI runs below.

Is it maybe possilbe to deduplicate those and have one canonical location for them?
E.g. vendoring these types from this repo in the terraform repo, or the other way around?
Or creating a common module that both repos can depend on?

Expected Behavior

No panic

Actual Behavior



@LorbusChris LorbusChris added the bug Something isn't working label Dec 4, 2019
Copy link

radeksimko commented Dec 6, 2019

Hi @LorbusChris
Unfortunately providers were never designed to be imported as Go packages in other Go projects and their APIs don't provide any guarantees. I'm sorry we weren't clear about it before, but @paddycarver does a great job at explaining it in this docs page which is soon to be merged and published on This will hopefully discourage more people from doing that.

The same page also describes how you can interact with Terraform in a supported way and what to do if the use case (presumably reason you are importing today) isn't supported.

E.g. vendoring these types from this repo in the terraform repo, or the other way around?

One of the main motivations behind separating SDK from core was to cut down the number of dependencies (esp. transitive dependencies). We would effectively revert all this (still ongoing) effort by making SDK import core as we'd bring core's dependency tree back to providers.

The longer term plan is to cut out SDK logic from core and core logic from SDK (there's currently still a lot of duplicated packages) and also to cut out RPC logic from both. As the code you're referring to is related to the old RPC protocol, there will be very little motivation to invest any effort into extracting it as we'd rather see it gone.

Generally speaking I would suggest you to review the reasons for importing providers and discuss your use cases in the Terraform Core issue tracker.

Copy link

LorbusChris commented Dec 6, 2019

@radeksimko thank you for providing context on this. Is there an open issue to track the removal of that RPC code?

Copy link

radeksimko commented Dec 7, 2019

@LorbusChris Removal of the old RPC protocol is related to our plans for deprecating Terraform 0.11, as all past versions (prior to 0.12) speak that protocol. We have published a blogpost outlining this plan for some major providers at

On SDK's side you can track any issue labelled as proto-5-only which we use to label features that can only be delivered to a provider that speaks proto 5 (i.e. gRPC) and not netRPC anymore (proto 4). In other words these features require us to break backward compatibility on the protocol level.

I can say that this is one of our priorities, but we want to get the communication part done right too and provide folks some time to migrate away from older Terraform versions.

Copy link

ghost commented Mar 30, 2020

I'm going to lock this issue because it has been closed for 30 days . This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@hashicorp hashicorp locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
bug Something isn't working
None yet

No branches or pull requests

2 participants