Previously, we called the `peek_enabled?` method like so:
prepend_before_action :set_peek_request_id, if: :peek_enabled?
Now we don't have a `set_peek_request_id` method, so we don't need that
line. However, the `peek_enabled?` part had a side-effect: it would also
populate the request store cache for whether the performance bar was
enabled for the current request or not.
This commit makes that side-effect explicit, and replaces all uses of
`peek_enabled?` with the more explicit
`Gitlab::PerformanceBar.enabled_for_request?`. There is one spec that
still sets `SafeRequestStore[:peek_enabled]` directly, because it is
contrasting behaviour with and without a request store enabled.
The upshot is:
1. We still set the value in one place. We make it more explicit that
that's what we're doing.
2. Reading that value uses a consistent method so it's easier to find in
future.
Peek attempts to serialize results with `to_json`, which calls
`ActiveSupport::JSON`. If an object is passed to `to_json` that contains
instance variables, `ActiveSupport` will attempt to recursively traverse
all variables.
The problem is that we can get into an infinite loop if the instance
references to an instance that references to something else that points
back to the same instance.
To avoid this mess, we just call `to_s` on the object. It appears only
`Gitlab::Git::Repository` and `::Repository` are the culprits here.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/65404
This will help diagnose the source of excessive I/O from Rugged
calls. To implement this, we need to obtain the full list of arguments
sent to each request method.
Sean McGivern