rails_pod_kit 0.0.2 → 0.0.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 01df88e896cc7b8aac64c01bd55b33be595cea12690fd0b0e47aa4b1289f5d95
-  data.tar.gz: fec8ba424464b8b15c20fe8c87b604fea5b667f42df9908921c13ac42a66e3ba
+  metadata.gz: 24c0e428faf1a3c46646a1d7a0e693b5cde8373f6aea61f9dc005d6b6dcba192
+  data.tar.gz: 968fc08545c75f5b22f91c2c882068b20069d7bb2bb6f48d1abf2aa09f4bc71b
 SHA512:
-  metadata.gz: a2b637351c73a11dcb83f5e4db150ae75bbcf61840af4a4262fd6063fce1a3069912ccea5031ccb84d90513aebf33e193614f5c05703835706a769ca59e675d4
-  data.tar.gz: b8c3b5682c277f6e5b39267454c820e206635c93e8fd74620e43ec673f1367e8c11c8585fcd914814d5e7db7655578352cebec492493eb4cc73e9f483aa59b87
+  metadata.gz: 266b27abb0911f031e54522dfcea870d603e1ec143465b4441a206590654087c1604a9aeb4438745bc10600bf3696b7d4938c0c936e0145322b76cb0279a5513
+  data.tar.gz: dedc4665fb51d38b9e713caead650ee875108aed4a24e9f27bb3053f2ec0152bdcc0f3840cc0ac76056858f330b723c502bc5f66d726261db47a7033e6ae2142

data/README.md

@@ -332,7 +332,12 @@ Booting the full host app just to read a handful of Redis counters would cost
   require only the config core, so the Rails-free exporter stays
   railties-free and a `puma -C config/puma.rb` boot (which evaluates
   `config/puma.rb` before Rails) still gets the integrations once
-  `Bundler.require` runs.
+  `Bundler.require` runs. The main file also loads the yabeda-prometheus-mmap
+  adapter at require time — before any host initializer runs — so host
+  initializers may declare Yabeda metrics (yabeda-rails, yabeda-activejob, a
+  custom collector) safely: the adapter registers itself while no metric exists
+  yet, regardless of whether the app boots via `bin/rails server` or
+  `puma -C config/puma.rb`.
 
 ## Local verification
 

data/VERSION

@@ -1 +1 @@
-0.0.2
+0.0.3

data/lib/rails_pod_kit/puma.rb

@@ -29,8 +29,10 @@ module RailsPodKit
 
       # The Puma plugin only pulls in the exporter class; we must also load the
       # full mmap module so `Yabeda::Prometheus::Mmap.registry` exists and the
-      # mmap adapter is registered (it's a transitive dep, so Bundler.require in
-      # the host app doesn't auto-require it).
+      # mmap adapter is registered. The gem's main entry (lib/rails_pod_kit.rb)
+      # already loaded it at Bundler.require, so this is normally a no-op — it
+      # matters only under `puma -C config/puma.rb`, where config/puma.rb runs
+      # before Rails and thus before the main entry, so this is the first require.
       require 'yabeda/prometheus/mmap'
 
       # The control app exposes Puma's /stats over a localhost-only socket that

data/lib/rails_pod_kit.rb

@@ -43,6 +43,19 @@ require 'rails_pod_kit/config'
 #   - under `puma -C config/puma.rb` — where Puma evaluates config/puma.rb
 #     (and thus rails_pod_kit/puma) before Rails exists — this file is still
 #     fresh for Bundler.require, so the integrations load once Rails is up.
+
+# Load the mmap adapter here — at Bundler.require, before any host initializer
+# runs — so its self-registration (`Yabeda.register_adapter` at require time)
+# happens while no Yabeda metric exists yet, making it a no-op. The adapter's
+# own `mmap.rb` requires the adapter *before* defining
+# `Yabeda::Prometheus::Mmap.registry`; if a metric is already declared when the
+# adapter loads, registration eagerly reaches for that not-yet-defined method
+# and boots crash with a NoMethodError. Under `bin/rails server` Rails boots
+# (and its initializers may declare metrics) before config/puma.rb requires the
+# adapter, so loading it here is what makes the order-of-boot irrelevant. The
+# lazy require in RailsPodKit::Puma.activate then degrades to a cheap no-op.
+require 'yabeda/prometheus/mmap'
+
 require 'rails_pod_kit/sidekiq'
 require 'rails_pod_kit/health'
 require 'rails_pod_kit/railtie'

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: rails_pod_kit
 version: !ruby/object:Gem::Version
-  version: 0.0.2
+  version: 0.0.3
 platform: ruby
 authors:
 - Fabio Napoleoni