Skip to content

Provide source of truth for identifying application type

This was broken out of #35170 (closed), which in return is a follow up to #32562 (closed) and #35559 (closed).

Need

We identified the need to reliably identify the current execution context in order to dynamically set configuration at runtime. By execution context we mean the kind of process that's running, such as an application server (puma, unicorn) or sidekiq. By defining a Ruby API that allows us to query for e.g. sidekiq? or puma?, we can inject system specific configuration more conveniently. These concerns are currently spread across the codebase and often encoded as defined?(::Constant) checks, which can be unreliable.

Approach

Provide a single source of truth that determines which context we're in and that can be used to drive things such as configuration decisions. Determining the kind of process running needs to be reliable and work across different kinds of deployments (local/GDK, local/GCK, ominibus, etc.)

One suggestion was to inject our own constants defining the current execution context as part of the run scripts, as the entry points differ across different environments. Another option could be to reflect on the process name, which might be less reliable, however.

Benefits

Gets rid of custom checks across the codebase and unifies them in a consistent and reliable way.

Competition

  1. Leave as is; we know this to work, but consider it tech debt that will only grow over time. We already accrued a bit more with the migration to Puma so now seems to be the inflection point beyond which we shouldn't put it out any longer.

  2. Centralize the checks, but use the same methodology as before, i.e. check for defined? ::Puma etc. This will reap some benefits and is less work compared to injecting our own constants, but could potentially lead to situations where more than 1 runtime identifies itself to be "present", which seems risky.

  3. Use wrapper scripts as outlined in Approach, but instead of injecting Ruby constants, use environment variables (UNICORN=true). The benefit is that we can hook into existing shell scripts like bin/background_jobs. The drawback of this is that it's highly mutable and could lead to surprising situations where configuration does not represent reality.