More gracefully reject colonCompoundIDs that aren't compound IDs #762
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What's the problem?
Attempts to plan a resource import fail with a panic where the provider expects special colon delimited resource IDs ... that don't contain a colon (whoops). An example of such a resource is a
team_membership
, whose ID is a colon separated userID and teamID.These changes help the provider more gracefully fail on these user errors instead of causing the provider to panic.
Specifically
A plan with the following Terraform configuration (IDs redacted):
...results in the following panic:
How does this fix it?
These changes have the parser for compound resource IDs surface a descriptive error instead of causing panic.
The resulting plan becomes:
Note to reviewers
Note that I attempt to maintain behaviour where >2 component IDs are passed in, even so we should technically fail for component IDs that don't have exactly two components. Not sure how much you want to focus the behaviour changes from bugfixes like this, but we can discuss.