Best way to debug API failures?

[hybby]

Hello!

We've been using this provider for some time (currently running the latest version, 2.30.0), and recently we've started receiving errors with the sumologic_content resource (which we use to create SavedSearchWithScheduleSyncDefinition objects which we pass to config ensuring it's wrapped in jsonencode()). Without having had made any recent changes to our code, stacks which previously applied fine have started throwing errors.

The error returned from the provider on apply (but not plan) is:

 │ Error: async job failed - {content1:internal_error Unexpected error }

I'm able to reproduce the issue under older provider versions too, such as 2.15.0. As such, I believe that this is indicating a failure interacting with the call to the SumoLogic API which must have changed or become stricter recently. However, with no details in the message, it's difficult to troubleshoot or debug any further.

Setting TF_LOG to DEBUG doesn't yield much more, but the most interesting error is:

 2024-05-31T14:59:56.883Z [WARN]  Provider "registry.terraform.io/sumologic/sumologic" produced an invalid plan for module.<omitted>, but we are tolerating it because it is using the legacy plugin SDK.
     The following problems may be the cause of any confusing errors from downstream operations:
...

  - .config: planned value cty.StringVal(...omitted...) does not match config value cty.StringVal(...omitted...) nor prior value cty.StringVal(...omitted...)

Unfortunately it's difficult for me to provide the full object redacted due to the amount of our information inside, so apologies for that.

Comparing the first and second omitted objects above, I see that there are some attributes on the second object that are not on the first (namely search.queryParameters: [], searchSchedule.parameters: [] and searchSchedule.parseableTimeRange.to: null which are possibly required additions to an API call's payload requirements for a webhook configuration that we have not yet implemented?

The above is all largely assumption and deduction, but I guess my actual question is...

Is there a way to increase debug or verbosity of the provider so that we get a better error back from the SumoLogic API? If my payload is malformed, the provider should hopefully be able to tell me why?

[hybby]

The question around how to debug more effectively is still valid, but I think the overall issue I'm trying to resolve is that Realtime Scheduled Search creation (and presumably updating) has been deprecated. We'll need to move to Monitors.

Just dropping this here in case anyone else's search terms guide them to this issue:

https://help.sumologic.com/release-notes-service/2024/04/30/scheduled-search-alerts/