Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix and Enable go-mnd Linter for resource.Retry and resource.RetryContext Arguments #16753

Closed
bflad opened this issue Dec 14, 2020 · 3 comments
Closed
Labels
linter Pertains to changes to or issues with the various linters. provider Pertains to the provider itself, rather than any interaction with AWS. stale Old or inactive issues managed by automation, if no further action taken these will get closed. technical-debt Addresses areas of the codebase that need refactoring or redesign.

Comments

@bflad
Copy link
Contributor

bflad commented Dec 14, 2020

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

NOTE: This requires upstream golangci-lint implementation work and release first.

The go-mnd analyzer is a magic number detector for Go. It currently is supported in golangci-lint, however we do not enable it because it currently would have many false positives for our codebase. These false positives stem from schema validation and other cases where the magic numbers are determined by the AWS APIs, but not modeled as a constant we can reference in the AWS Go SDK, e.g.

aws/data_source_aws_codeartifact_authorization_token.go:33:28: mnd: Magic number: 900, in <argument> detected (gomnd)
					validation.IntBetween(900, 43200),
					                      ^

In particular though, one needed use case for go-mnd reports is usage of resource.Retry() and resource.RetryContext() calls where the time.Duration is a magic number. Many resources use this type of logic to handle eventual consistency issues in the API, however keeping them properly in sync is hard without a single constant to reference.

In the future, we can determine how useful (and painful) it might be to enable go-mnd on other functions or detection types (such as assignment).

Affected Resources

This will be updated when appropriate.

References

@bflad bflad added technical-debt Addresses areas of the codebase that need refactoring or redesign. provider Pertains to the provider itself, rather than any interaction with AWS. linter Pertains to changes to or issues with the various linters. labels Dec 14, 2020
@bflad bflad self-assigned this Dec 14, 2020
@bflad
Copy link
Contributor Author

bflad commented Dec 14, 2020

Once golangci/golangci-lint#1557 is resolved, released, and the dependency is updated here, this configuration should get us close:

linters-settings:
  gomnd:
    settings:
      mnd:
        checks:
          - argument
        ignored-functions:
          - aws.Int64
          - schema.DefaultTimeout
          - validation.FloatBetween
          - validation.IntAtLeast
          - validation.IntBetween
          - validation.StringLenBetween

bflad added a commit that referenced this issue Feb 25, 2021
…enabling go-mnd linter

Reference: #13199
Reference: #16752
Reference: #16753

IAM eventual consistency handling has long been the source of needing retries in resource logic. Due to the lack of a consistent implementation (e.g. static constant) for how long to retry for these types of errors, there have been varying retry durations. The `iamwaiter.PropagationTimeout` constant was introduced for this purpose.

This change begins by introducing the `go-mnd` linter to enforce the usage of constants in function arguments. Example reports below. The rest of the changes are the minimum required to ensure `iamwaiter.PropagationTimeout` with its 2 minute duration is applied. You will note that this is fixing the duration in some cases to slightly increase it to the standard value. Any higher durations are ignored to reduce changes for now. As such, this can be reviewed by validating that a lower duration was not introduced and skipping acceptance testing since no logic changes should be introduced.

One caveat to `go-mnd` is that it currently ignores `1` as a magic number, which is possible in usage such as `1*time.Minute`, and that ignored number cannot be overriden. An upstream issue will be created to ask the `ignore-number` configuration to overwrite instead of append.

Example previous report:

```
aws/resource_aws_api_gateway_account.go:99:23: mnd: Magic number: 2, in <argument> detected (gomnd)
	err = resource.Retry(2*time.Minute, func() *resource.RetryError {
	                     ^
```
bflad added a commit that referenced this issue Mar 22, 2021
…enabling go-mnd linter

Reference: #13199
Reference: #16752
Reference: #16753

IAM eventual consistency handling has long been the source of needing retries in resource logic. Due to the lack of a consistent implementation (e.g. static constant) for how long to retry for these types of errors, there have been varying retry durations. The `iamwaiter.PropagationTimeout` constant was introduced for this purpose.

This change begins by introducing the `go-mnd` linter to enforce the usage of constants in function arguments. Example reports below. The rest of the changes are the minimum required to ensure `iamwaiter.PropagationTimeout` with its 2 minute duration is applied. You will note that this is fixing the duration in some cases to slightly increase it to the standard value. Any higher durations are ignored to reduce changes for now. As such, this can be reviewed by validating that a lower duration was not introduced and skipping acceptance testing since no logic changes should be introduced.

One caveat to `go-mnd` is that it currently ignores `1` as a magic number, which is possible in usage such as `1*time.Minute`, and that ignored number cannot be overriden. An upstream issue will be created to ask the `ignore-number` configuration to overwrite instead of append.

Example previous report:

```
aws/resource_aws_api_gateway_account.go:99:23: mnd: Magic number: 2, in <argument> detected (gomnd)
	err = resource.Retry(2*time.Minute, func() *resource.RetryError {
	                     ^
```
bflad added a commit that referenced this issue Mar 26, 2021
…enabling go-mnd linter (#17811)

Reference: #13199
Reference: #16752
Reference: #16753

IAM eventual consistency handling has long been the source of needing retries in resource logic. Due to the lack of a consistent implementation (e.g. static constant) for how long to retry for these types of errors, there have been varying retry durations. The `iamwaiter.PropagationTimeout` constant was introduced for this purpose.

This change begins by introducing the `go-mnd` linter to enforce the usage of constants in function arguments. Example reports below. The rest of the changes are the minimum required to ensure `iamwaiter.PropagationTimeout` with its 2 minute duration is applied. You will note that this is fixing the duration in some cases to slightly increase it to the standard value. Any higher durations are ignored to reduce changes for now. As such, this can be reviewed by validating that a lower duration was not introduced and skipping acceptance testing since no logic changes should be introduced.

One caveat to `go-mnd` is that it currently ignores `1` as a magic number, which is possible in usage such as `1*time.Minute`, and that ignored number cannot be overriden. An upstream issue will be created to ask the `ignore-number` configuration to overwrite instead of append.

Example previous report:

```
aws/resource_aws_api_gateway_account.go:99:23: mnd: Magic number: 2, in <argument> detected (gomnd)
	err = resource.Retry(2*time.Minute, func() *resource.RetryError {
	                     ^
```
Copy link

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

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

@github-actions github-actions bot added the stale Old or inactive issues managed by automation, if no further action taken these will get closed. label Dec 27, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 4, 2024
Copy link

github-actions bot commented Mar 6, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
linter Pertains to changes to or issues with the various linters. provider Pertains to the provider itself, rather than any interaction with AWS. stale Old or inactive issues managed by automation, if no further action taken these will get closed. technical-debt Addresses areas of the codebase that need refactoring or redesign.
Projects
None yet
Development

No branches or pull requests

1 participant