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

When not retrying a request, log reason at info level #1189

Merged
merged 1 commit into from
Sep 23, 2020

Conversation

brandur
Copy link
Contributor

@brandur brandur commented Sep 23, 2020

This patch follows up #1187 by having shouldRetry return a second
string value when no retry should be attempted which contains a short
informational message as to why there should be no retry. A caller can
use this for logging/informational purposes to make the retry system
less opaque.

r? @ctrudeau-stripe For review.

Also cc @remi-stripe who requested this feature.

cc @stripe/api-libraries

This patch follows up #1187 by having `shouldRetry` return a second
string value when no retry should be attempted which contains a short
informational message as to why there should be no retry. A caller can
use this for logging/informational purposes to make the retry system
less opaque.
&http.Response{},
int(MaxNetworkRetries),
))
t.Run("DontRetryOnExceededRetries", func(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also refactored this test case to use subtests, which is a pretty typical pattern in Go. This has a few advantages:

  • Subtests run inside their own closure func ... { ... } so variables are localized to them, which means variables can't leak into other subtests and keeps things generally cleaner.
  • Go tooling allows us to run any specific subtest with -name so we can target exactly one of them without having to run every single one.

int(MaxNetworkRetries),
))
t.Run("DontRetryOnExceededRetries", func(t *testing.T) {
shouldRetry, _ := c.shouldRetry(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not checking against the returned message because:

  • The boolean is by far the more important value.
  • Messages aren't super likely to regress in an important way.
  • Not checking the messages means that it's easier for us to change one because we don't have to update the test case as well.

return false, "context deadline exceeded"
default:
return false, fmt.Sprintf("unknown context error: %v", req.Context().Err())
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really nice.

Copy link
Contributor

@ctrudeau-stripe ctrudeau-stripe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚢 :shipit:

@brandur-stripe
Copy link
Contributor

Thank you Chris!

@brandur-stripe brandur-stripe merged commit e7c54ca into master Sep 23, 2020
@brandur-stripe brandur-stripe deleted the brandur-log-no-retry-reason branch September 23, 2020 23:10
@brandur-stripe
Copy link
Contributor

Released as 72.6.0.

nadaismail-stripe pushed a commit that referenced this pull request Oct 18, 2024
* try test fixes

* only run unit tests

* add logs to locker test

* try smth

* run all tests

* test

* test

* disable wait on played back recordings

* fix test translator

* fix revenue contract

* reset ci

* remove accidnetal changes from test_evergreen_order

* remove accidental puts

* move env in translator to before

* fix gem audit error

* fix bundle audit

* fix tc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants