Add sufficient context when letting user report errors

[abergmeier]

Module version

0.6.1

Relevant provider source code

The framework currently has a lot of places where the user is quested with reporting errors to the provider developer:

Please report the following to the provider developer

Expected Behavior

The provider developer needs as much internal state as possible to be able to diagnose the problem.

Actual Behavior

Currently every single time I encountered this I pretty much had to go into the source and add panics to framework code and or additional error reporting.
I really loathe releasing a framework provider and getting this little error context in the wild.

Actually I just noticed that there is not a single test, which validates these errors.

References

[bflad]

Hi @abergmeier 👋 Thank you for reporting this and sorry you had a frustrating experience. Indeed, the framework should do a better job providing breadcrumbs for troubleshooting about what it is doing as we ready it for a v1.0.0 release.

First things first, #300 should cover a lot of handoffs between the framework and provider defined logic. That should at least leave more clues about when these errors are thrown as it relates to places where the provider has certain influence on the situation.

I notice you submitted #284 specifically for some internal/reflect handling. That package certainly needs some observability improvements.

I'd love to hear more from you about what you mean by "as much internal state as possible to be able to diagnose the problem" -- just so we can level set and ensure your ask is being met. Ideally, error messaging should be made clear so this level of debugging is not strictly necessary. If you have specific cases where you feel this is lacking, I think we'll need some more context about how to ensure there is production-ready observability in those cases. Otherwise, this issue could be quite ambiguous for what qualifies as a "definition of done".

Thanks again and looking forward to working on this with you.

[bflad]

Hi again, @abergmeier. Since I didn't hear back from you about anything specific here, I'm going to close this issue for now so we can keep track of actionable work. That is certainly not to say this feedback isn't valuable though, we would still love to hear about any specific cases where the error messaging can be improved, which can be done in new GitHub issues. Thanks again for raising this.

If you're still interested in working on #284, please reach out on that pull request. We have some other internal reflection package changes that are in that area so we will either need to take those code changes into consideration or close that out if it becomes out of date.

[github-actions]

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.