Honeycomb Beeline changes Rails initialization order to run Railties after config initializers are complete, breaking Sequel-Rails

[qnm]

Use of the honeycomb-beeline gem changes the initialization order, due to its use of after: :load_config_initializers in the Railtie. This prevents using a Sequel database connection within config/initializers when gems such as sequel-rails (which use Railties to configure a connection) are used.

Specifically, this is the error I see:

Sequel::Error:
  No database associated with Sequel::Model: have you called Sequel.connect or Sequel::Model.db= ?

Versions

• Ruby: 2.6.8
• Beeline: 1.5.0

Steps to reproduce

I've been unable to reproduce this in a toy app, nevertheless I will try to explain the issue using references.

1. Install the honeycomb-beeline gem, ensuring that the railtie integration is active.
2. Using an initializer e.g. config/initializers/flipper.rb attempt to use a gem that is configured by a Railtie. One example would be https://github.com/TalentBox/sequel-rails which I use to integrated the Sequel gem with Rails. I am using the flipper-sequel gem to feature flag, and configuring this gem requires the use of a database connection.
3. Observe this fails, as the sequel-rails Railtie executes after config/initializers due to the Beeline's use of load_config_initializers.
4. This issue is alluded to in rails/rails@0a120a8

Additional context

This project rack/rack-attack#456 had a similar problem, and that issue includes a workaround (which I have adopted, which is to require sequel-rails early in the initialization process) and their solution: rack/rack-attack#457

I'm a somewhat niche case here, using the Sequel gem with sequel-rails inside Rails, and this bug was only apparent when I started using flipper-sequel. Noting here so others may find it in future!

[robbkidd]

@qnm, thanks for this issue and the details. It's on the queue to investigate further.

[robbkidd]

@qnm I've attempted a few different ways to initialize the Beeline's Railtie in a backwards-compatible way without success. I think for the time being, we'll need to document this situation better. Can you share the error message you see during initialization without your "require "sequel-rails" in an initializer" workaround? That could help with the search-fu for others to find in the future.

Rails initialization is sometimes a Dark Art. I see two workarounds:

1. The one you discovered: require the gems that have initialization issues when used with load_config_initializers triggered.
2. Opt-out of the Beeline's Railtie. The Beeline loads the integrations listed in the Honeycomb::INTEGRATIONS constant. That is overridable with an environment variable HONEYCOMB_INTEGRATIONS, an "allow" list of integrations. Set that to only the integrations you wish to load—in this case, omit railtie—and then you have control over the timing of insertion of the Beeline's Rails middleware, probably to be added to your config/initializers/honeycomb after the configuration.

[qnm]

Hi @robbkidd,

I'm back at work now, and just quickly following up here.

Can you share the error message you see during initialization without your "require "sequel-rails" in an initializer" workaround?

I can - however the error is specific to the gem I am using. The error relates to a database connection not being initialised. It's exactly as-per rack/rack-attack#456 which was the issue that guided me to my eventual conclusion and this issue. I've updated the original comment with this text for later search.

My thoughts on the two options presented:

1. This is a fine approach, only really requires maintaining a list of known 'problem' gems and perhaps a note about load_config_initializers, though I've used Rails for years and never hit any issues relating to load_config_initializers before. It was a fun deep dive ;)

2. My main issue with this approach is the use of ENV to control the loading, which may sit outside of source control and therefore reappear on developers laptops without warning. It would be nice if this same mechanism could be configured in code.

Thanks for looking into this.

[robbkidd]

I've managed to fiddle Option 2 into code contained to a config/initializers/honeycomb.rb, but it's nothing that ought to see the light of day. I killed it with fire.

I'm going to close this issue for the time being, with it's documented workaround for a Rails app to perform its own requires at the appropriate time for libraries affected.