Closed billycn20 closed 5 months ago
@anushjay can i get some assistance on how to move forward with getting this PR reviewed?
@billycn20 there is a real need for better feedback from the client back to the Terraform provider, but I think it needs to be provided directly, not just via DEBUG logs, which then have to be examined by a person for most failures.
Specifically, when a create fails, the provider should know it was unsuccessful, and report that via the returned diagnostic message. Additionally, when a read fails, it should be possible to differentiate between "this object was not found" and "this request failed for another reason."
My overall thought is this need would be best met by refactoring how the included Client
performs requests and handles responses. I am working on this concept by abstracting the Client
into a separate Splunk SDK for Go, but I don't have a timeline for if or when this could be available.
TLDR: yes, we need better signaling, but it needs to be more formally implemented.
@billycn20 found your code very helpful - thank you! Pity this can't be in place for those experiencing issues that this exposes.
@billycn20 found your code very helpful - thank you! Pity this can't be in place for those experiencing issues that this exposes.
Thank you @khalilnkhaliln. Glad you found it helpful. I struggled to find the errors when i was debugging the provider so hoped others would benefit from this too.
@billycn20 Can you please run the test workflow action for this branch? If it passes I can merge and create a new release with these changes.
@billycn20 Can you please run the test workflow action for this branch? If it passes I can merge and create a new release with these changes.
Sure, can you explain to me the steps to do that?
@billycn20 Can you please run the test workflow action for this branch? If it passes I can merge and create a new release with these changes.
Sure, can you explain to me the steps to do that?
I believe that pushing a commit to a PR targeted at the master branch should automatically trigger the workflow actions. I am not sure why it didn't the first time, perhaps the workflow wasn't automated then. Can you try pushing something again?
Currently the provider does not give a good explanation of http response on status codes such as 400, < 500 . This logging is going to be helpful when debugging provider issues and give developers explanation of what the response contains.