fix(tls/subscriptions): tls configuration id should always be passed #670
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.
Fixes: #669
Problem: A customer noticed when modifying their TLS Subscription domains that an error was reported saying a TLS Configuration ID was missing. This was caused by the customer not having a default TLS Configuration set, only custom configuration objects (one of which they specify the ID for in their HCL config). But because that ID wasn't changing, the current TF implementation wouldn't send it in the API request, and so the API returned an error because it expected an ID.
Solution: We always provide the TLS Configuration object ID. Even if the customer has a default TLS Configuration object set on their account we'll still pass whatever the computed ID was to ensure the API doesn't error.
NOTE: I've run the complete end-to-end integration test suite and it's passing.