Commits on Mar 10, 2022

1. configs: Refined error messages for mismatched provider passing …

   This set of diagnostic messages is under a number of unusual constraints
   that make them tough to get right:
    - They are discussing a couple finicky concepts which authors are
      likely to be encountering for the first time in these error messages:
      the idea of "local names" for providers, the relationship between those
      and provider source addresses, and additional ("aliased") provider
      configurations.
    - They are reporting concerns that span across a module call boundary,
      and so need to take care to be clear about whether they are talking
      about a problem in the caller or a problem in the callee.
    - Some of them are effectively deprecation warnings for features that
      might be in use by a third-party module that the user doesn't control,
      in which case they have no recourse to address them aside from opening
      a feature request with the upstream module maintainer.
    - Terraform has, for backward-compatibility reasons, a lot of implied
      default behaviors regarding providers and provider configurations,
      and these errors can arise in situations where Terraform's assumptions
      don't match the author's intent, and so we need to be careful to
      explain what Terraform assumed in order to make the messages
      understandable.
   
   After seeing some confusion with these messages in the community, and
   being somewhat confused by some of them myself, I decided to try to edit
   them a bit for consistency of terminology (both between the messages and
   with terminology in our docs), being explicit about caller vs. callee
   by naming them in the messages, and making explicit what would otherwise
   be implicit with regard to the correspondences between provider source
   addresses and local names.
   
   My assumed audience for all of these messages is the author of the caller
   module, because it's the caller who is responsible for creating the
   relationship between caller and callee. As much as possible I tried to
   make the messages include specific actions for that author to take to
   quiet the warning or fix the error, but some of the warnings are only
   fixable by the callee's maintainer and so those messages are, in effect,
   a suggestion to send a request to the author to stop using a deprecated
   feature.
   
   I think these new messages are also not ideal by any means, because it's
   just tough to pack so much information into concise messages while being
   clear and consistent, but I hope at least this will give users seeing
   these messages enough context to infer what's going on, possibly with the
   help of our documentation.
   
   I intentionally didn't change which cases Terraform will return warnings
   or errors -- only the message texts -- although I did highlight in a
   comment in one of the tests that what it is a asserting seems a bit
   suspicious to me. I don't intend to address that here; instead, I intend
   that note to be something to refer to if we later see a bug report that
   calls that behavior into question.
   
   This does actually silence some _unrelated_ warnings and errors in cases
   where a provider block has an invalid provider local name as its label,
   because our other functions for dealing with provider addresses are
   written to panic if given invalid addresses under the assumption that
   earlier code will have guarded against that. Doing this allowed for the
   provider configuration validation logic to safely include more information
   about the configuration as helpful context, without risking tripping over
   known-invalid configuration and panicking in the process.

   

   apparentlymart committed Mar 10, 2022
   Copy the full SHA

   cb3450f View commit details

   Browse the repository at this point in the history