Terraform: Output on plugin API mismatch is misleading

[rtizzy]

Terraform Version

Terraform v0.8.8

Affected Resource(s)

Custom providers that have API mismatches

Expected Behavior

A clear error should be provided that indicates the plugin version is mismatched with the current API version of terraform. It should then output the version of each.

The output should be something like the following.

* Incompatible API version with plugin '_terraform-provider-example_'. Terraform API version: 4, Plugin API Version: 2

Actual Behavior

The error provided has misleading language that does not clarify what actually has the version mismatch (Terraform or the Provider). "Ours" would seem to indicate the API version of terraform but instead indicates the version of the plugin

• Incompatible API version with plugin. Plugin version: 4, Ours: 2

Steps to Reproduce

1. Install a provider with a API mismatch.
2. Attempt to interact with the plugin.

Updated with suggestions by @ekhaydarov.

[ekhaydarov]

How does one actually change the plugin version? I cant seem to find it in the docs

edit: Update the vendors

However would it be possible to output which plugin is incompatible with the api version? I have multiple plugins and have no idea which one is failing.

Something like:
* Incompatible API version with plugin 'terraform-provider-example'. Terraform API version: 4, Plugin API Version: 2

[mitchellh]

We should definitely be able to improve this in every way recommended here. Thanks!

[apparentlymart]

Sorry for the long silence here, all!

The situation here has already changed quite a lot since v0.8.8 because we switched to downloading and installing providers separately during terraform init. However, we've been using this issue to represent making sure that Terraform is able to produce better error messages when protocol versions mismatch during that automatic installation step.

The recent PRs #19977, #19976, and #19981 have introduced new messages that talk about which available versions are compatible rather than directly about the protocol versions. We will continue to iterate on this in future releases, since the existing installer architecture constrained how much we could change without risky refactoring, but I think what we've done so far is enough to close this out since it is now far more actionable than it was in v0.8.8.

Thanks for reporting this @rtizzy, and sorry for taking so long to address it!

[hashibot[bot]]

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.