Skip to content

Wrap requests in an ApplicationContext

What does this MR do?

This provides context to all requests made to Rails controllers or grape endpoints.

Doing this starts a new Labkit::Context, to which we can provide a namespace, project and user.

We're currently setting the following values:

  • Web requests: In the ApplicationController we wrap the entire request in a with_context.

    • user: based on the auth_user if there is one
    • project: We try to read the @Project instance variable of the controller.
    • namespace: We try to read the @group instance variable of the controller. If there was none, but the project was set, we'll use that path to set the namespace
  • API requests: The application context is pushed in a before block setting the following values:

    • user: to current_user if there is one
    • project: to @project
    • namespace: to @group
  • Internal API requests: the application context is pushed in a before block:

    • user: When to the user set in Api::Support::GitAccessActor
    • project: to @Project if it was available

The 3 supported attributes for a context are read lazily when required.

This also replaces the existing correlation middlewares with the new Labkit::Context middlewares.

The rack middleware wraps each rack request in an overarching context that adds the correlation id. The context is cleaned up after the request, so we're sure all child contexts are cleaned up as well.

The sidekiq client middleware will write the context into the job that goes into redis when a job is scheduled.

The sidekiq server middleware will then re-instantiate this context so the job gets executed with the same context that was alive when it was scheduled. This means that any new job scheduled from sidekiq would also have this context.

Part of gitlab-com/gl-infra/scalability#9 (closed)

Conformity

Availability and Testing

Edited by Bob Van Landuyt

Merge request reports