Add context with metadata and correlation

The context can be passed from the client applications as a hash.

Every time a new context is added, it will inherit the values of the previous context. Those previous values will be overridden by any new ones passed.

A context always has a correlation id that is not empty. If an empty correlation id is passed, a new one will be generated.

There is a Labkit::Middleware::Rack that will set the correlation id to the current request id. Because of this, every newly started context within a rack request will get the same correlation id.

Using the Labkit::Middleware::Sidekiq::Client middleware the context active at the moment of scheduling a job will be serialized into the job.

The Labkit::Middleware::Sidekiq::Server middleware will load the context that was stored on the job, so newly scheduled jobs would start with the same context. This context could be modified by the job.

In this iteration the following extra values can be specified on the context:

• user
• project
• root_namespace

Usage of the Labkit::Context

The preferred way of specifying a context is using a block:

  Labkit::Context.with_context(
    user: 'jane.doe',
    project: 'jane.doe/cool'
  ) do |context|
    # application code
  end

If there's no way to wrap the application code into a block (for example for the grape api), then context can be pushed and popped:

  def context
    @context ||= Labkit::Context.push(user: 'jane.doe')
  end

  before { context }
  after { Labkit::Context.pop(context) }

It is possible to provide procs when assigning values to the context:

  Labkit::Context.with_context(user: -> { current_user }) { # ... }

This proc will only be executed when needed: When serialising the context into a log or a job. This happens when calling Labkit::Context.to_h.