handle ratelimits for reading user groups

[svenwltr]

Attempt to fix #64

This currently only handles the slack_usergroup, but other resources can be adapted to it.

Instead of the suggestion to use github.com/cenkalti/backoff, I used the built-in retry mechanism of Terraform provider API: https://www.terraform.io/docs/extend/resources/retries-and-customizable-timeouts.html#retry. This has the advantage that the user can leverage the Terraform-native timeouts:

resource "slack_usergroup" "my_group" {
  name        = "TestGroup"
  handle      = "test"
  description = "Test user group"
  users       = [data.slack_user.test_user_00.id]

  timeouts {
    reaad = "10m"
  }
}

The backoff with jitter is inspired by a AWS blog post: https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/

Open questions:

• Where to put the backoff code?
• Should the max config time be configurable? If yes, where and if no what should the value be?
• Same question for the base timeout?

[pablovarela]

Thanks a lot for your contribution! Apologies it took me so long to come back to you, I started a new rol recently and I didn't have the time to look into this.

To answer your questions:

Where to put the backoff code?

The project is so small that I am not too worried about where the backoff implementation goes, as far as it is in its own file i.e. do not leave in the user group resource. I will leave it to you to move it backoff.go in the slack package we currently have, or move it to its own package.

Should the max config time be configurable? If yes, where and if no what should the value be?

I think it should. I would make it part of the provider options, just add it to the provider schema in provider.go and make it optional with a sensible default.

We could make the timeout configurable per resource/datasource (also options in the schema) but I don't think it is necessary. If you want, and have the time, the most flexible solution would be to support default configuration, configuration at the provider level, and allow to override at the resource/datasource level.

I suggest to start with default + provider configuration. If we decide later we need this config per resource/datasource we can add it.

Same question for the base timeout?

Same answer as above.

Apologies again for the late response, and thanks for the contribution.

[github-actions]

Marking this pull request as stale due to inactivity. This helps our maintainers find and focus on the active pull requests. If this pull request receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this pull request was automatically closed and you feel this pull request should be reopened, we encourage creating a new pull request linking back to this one for added context. Thank you!

[nvcnvn]

Can we just apply this fix and release it in a new version?

[smoya]

We are being hit by this.