-
Notifications
You must be signed in to change notification settings - Fork 31
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
feat(common): Log requests and responses #1112
Conversation
be89659
to
3e27e01
Compare
3e27e01
to
aac8cf8
Compare
b35abcf
to
3a06e57
Compare
9ac59b0
to
d1272d2
Compare
d1272d2
to
733776a
Compare
|
||
class << self | ||
# @private | ||
def random_uuid4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote for SecureRandom.uuid
here, and then you don't even need to test it -- the algo looks nice though. We already use in a bunch of places for our repos and its a standard library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Main reason I chose to avoid SecureRandom here is that its internal implementation can theoretically block for brief periods of time (e.g. if /dev/urandom
is being used), and for logging purposes we have a fairly strict requirement against that. That said, there is Random::Formatter
(i.e. allowing Random.uuid
) which I would use except it seems to require Ruby 3.1, and we're not quite scheduled to drop 3.0 support yet until next spring.
@@ -64,6 +66,9 @@ class ServiceStub | |||
# be used for intercepting calls before they are executed Interceptors are an EXPERIMENTAL API. | |||
# @param channel_pool_config [::Gapic::ServiceStub:ChannelPool::Configuration] The configuration for channel | |||
# pool. This argument will raise error when `credentials` is provided as a `::GRPC::Core::Channel`. | |||
# @param logger [Logger,:default,nil] An explicit logger to use, or one |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No action, just saying I probably prefer the docstring order used here.
Having the parameter name
after @param
is easier to see. Example in google-cloud-ruby
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, agreed. A lot of our early development in google-cloud-ruby used the other ordering (type first). I think it might have been because earlier versions of YARD required that ordering. But I definitely prefer name-first now that YARD supports both.
733776a
to
7ea86c8
Compare
7ea86c8
to
68565f9
Compare
No description provided.