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

fix: validate implied provider names in submodules #31573

Merged
merged 1 commit into from
Aug 5, 2022

Conversation

radeksimko
Copy link
Member

Fixes #31572

Example config

(which triggers the bug)

./main.tf

module "test" {
  source = "./sub"
}

./sub/main.tf

resource "-test_test" "name" {
}

Before

Screenshot 2022-08-04 at 19 50 48

After

Screenshot 2022-08-04 at 19 51 26

Notes

There are also cases which may produce an extra error - assuming that the provider name is also invalid for HCL:

Screenshot 2022-08-04 at 19 54 37

I didn't spend much time on deduplicating it though as I'd expect/hope this is generally an error people will see quite rarely.

I chose to quote the original provider name in the error message, although the other existing diagnostic doesn't do that (uses %s instead of %q) - let me know if you prefer either. My preference for %q was primarily driven by making empty name and other short names with just special characters more visible and obvious.

{
"Key": "test",
"Source": "./sub",
"Dir": "testdata/invalid-names-in-submodules/sub"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was somewhat confused at first that all the modules in testdata have essentially fake Dir - if each dir was otherwise terraform inited directly, there wouldn't be testdata/invalid-names-in-submodules but only the last part (sub).

I'm not sure if that's intentional or not, just something I wanted to point out here.

@radeksimko radeksimko merged commit fc62afb into main Aug 5, 2022
@radeksimko radeksimko deleted the b-validate-implied-provider-in-submodules branch August 5, 2022 19:44
@github-actions
Copy link
Contributor

github-actions bot commented Aug 5, 2022

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

@radeksimko
Copy link
Member Author

@jbardin Is it worth back-porting this bug fix? Not sure what your convention is around this and how do you do it.

@jbardin
Copy link
Member

jbardin commented Aug 5, 2022

d'oh, I forgot to check for a backport label, but yes it's a simple fix causing crashes in the release, so that should be OK. if you could manually backport it to v1.2 that would be great!

In the future, if you apply a backport label before merging, the backport assistant will cherrypick the commits into a new PR for you.

@radeksimko
Copy link
Member Author

@jbardin See #31590

@github-actions
Copy link
Contributor

github-actions bot commented Sep 5, 2022

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Crash due to invalid provider address
2 participants