Hi @jharley 
Interesting topic and sounds like you have done some good investigative work here already.
Terraform resources (data resources or managed resources) are always considered separate, both in state storage and in operations, so your intuitions here about potential options are pretty accurate. If you attempted to do an API lookup during planning (a valid approach), but the separate resource has not been created in the API yet, then you would not get the validation. Passing the query configuration through to the trigger configuration guarantees that the trigger managed resource has all the information to perform the validation itself, but is less convenient than passing an identifier and being able to manage the resources separately (especially if the query is reusable elsewhere).
Upfront, I’m not sure if there is going to be a “best practices” type of answer here, but maybe some of these ideas can offer inspiration for your situation. It probably goes without saying you could go back to how it was with accepting the query specification directly in the trigger managed resource, but it really depends on your practitioner use cases and needs.
One option would be allow two configuration styles and ensure via configuration validation that they both cannot be defined at the same time:
- Configuration via query identifier as it is today. Queries remain “reusable”, separate managed resources but without the configuration-time or plan-time validation.
- Configuration via query specification where the trigger managed resource also internally manages and validates the query.
Another, maybe slightly more preferable, option could be allowing both configuration styles at the same time:
- Requiring configuration via query identifier as it is today. Queries remain “reusable”, separate managed resources.
- Optionally allowing configuration also via query specification, but only to enable the additional validation in the trigger managed resource.
Beyond that, there are other configuration-based options such as lifecycle precondition and friends, but understandably that could be less than ideal as every practitioner configuration must try to tease out the validation logic themselves, even if there is an example of this in the managed resource documentation.
Courtesy of the upcoming Terraform 1.8 provider-defined functions feature, you could however, make this easier for practitioners by offering a function that performs the necessary validation logic to catch the configuration issue (e.g. validate_trigger_frequency(query_duration, trigger_frequency) or passing in the whole query specification instead of the duration).
Another option in that space without provider-defined functions is offering additional computed attributes in the query managed resource to help practitioners write this validation logic themselves (e.g. max_trigger_frequency or similar).
I’m going to stop here because that is a lot of potential solutions for your situation and while none of these solutions may be ideal, I hope that these additional threads can give you something to pull on.
