reify the list values before validation

[jbardin]

If the list was marked as computed, all values will be raw config
values. Fetch the individual keys from the config to get any known
values before validating.

#12892

[mitchellh]

Looks good, quick question: what happens to the computed values? I can't remember but it looks like your test checks that none have the interpolation value, where does that value go?

I seem to recall we purposely send computed values into validate so that validate can know the EXISTENCE (won't error that you must set) but at the same time can check if it its computed. Want to verify if that's the case here?

[jbardin]

Hmm, that map in the test fixture schema looks little wonky (it was just there for good measure, not actually part of the bug). I'll fix that up.

[jbardin]

computed primitive values are skipped completely, so ValidateFunc should never have to deal with the raw interpolation strings or know about UnknownValue.

[mitchellh]

@jbardin An issue we ran into early then was the exists/not-exists check. For example: if an entire list is computed, will helper/schema properly see that some value may exist there in the future (and therefore pass validation)?

[jbardin]

@mitchellh, In this case the list is marked as computed (which is why we had all raw values), which would skip ValidateFunc for the list if it had one (I confirmed that). The individual elements are still validated independently.

If you're referring to Resource.ExistsFunc, that's called from a different code path

[mitchellh]

That works great.

Yeah not ExistsFunc that is to check if a resource exists via state (so never computed values) I think.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.