Ah, I found this which seems similar symptoms for the same ‘bug or feature’:
In my testing though, it would consistently work for the data source and not the resource, not the random race that seems to imply.
I’m not sure I understand the solution though - is Configure called multiple times if it exits without error or otherwise modifying the response? Otherwise, this doesn’t help, since I do need it to be configured - I just can’t do that if the provider configure hasn’t already run.
For what it’s worth, I think if you try to access ProviderData and it’s not set, but only because of the call order which is out of your control… If not a bug that’s a mis-feature, or one that could do with a clearer API. The docs do provide exactly this example use case of configuring a client on the provider, and then passing to resources/data sources to Configure.
For example - this will be hand-wavy because I don’t spend a lot of time with Go - if CRUD functions instead somehow declared or called a waiting function to say they needConfigure, the resource Configure could similarly say it needs provider Configure, and if either hasn’t already run it waits for it, even triggering it if necessary. Something along this line I think could fix the issue, but also push the flexibility of ‘it might not need it’ down further to the CRUD operations, not waiting for it to be configured if not necessary. (Delete for example is sometimes state-only even when others aren’t, and so wouldn’t need a client.)