rails_error_dashboard 0.11.1 → 0.11.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 4aa6cdee526bf9210f3762861a373dbefbe99b9ed94ecdb5f6464fb781bdddb4
-  data.tar.gz: 3a7977ff26332c869b5bf6e4e5316d3470e978ff736184dcc4119f0982822c4c
+  metadata.gz: ca64d9f0169fc1dd0b900fbd5460377d5b086d45849e61ca1945045db6c10e4e
+  data.tar.gz: e9c09c9c4d5c9b716bf4da5aec37d28780aa2bcbd8d2d80cdacbdd9fb171a0b4
 SHA512:
-  metadata.gz: ea46f47e2e96da83cf0c83d94596e63d63ab0dafeea5a3f696b2a1021b9eb57026485c9fec4d0827e8f8fcd4852fd587a69d28d3890ec14a5ec295d549826264
-  data.tar.gz: 4ea0ff21bbcb9177fd43297a5145e17a6316ec52f2f8a5370b30e36879a32810cd289b22e7c1d66abb2b9f9a66593bc2e013ab3ccfc19af1c0ffc46c42863537
+  metadata.gz: 51d6dc61b08748427205b7d3a838ec14e968f01898b395fa9f678c7aca3dd4647b32bc37f0e91fa1d99782b89242707d20604441a81ce7c7ca8bc2cbaa47d1e4
+  data.tar.gz: da69121a17eff452ea3b0d31c909b765da9e607cb1a80c5ae304a6fbb4c45473a88d3c6d7c927762d64ed1dd76630ca2dc4b9b37813cdd5213fbec9b7063fe29

data/app/jobs/rails_error_dashboard/rack_attack_flush_job.rb

@@ -6,11 +6,17 @@ module RailsErrorDashboard
   # Two usage modes:
   # 1. With a counts hash — dispatched by RackAttackTracker's periodic flush.
   #    Zero I/O in the request path; all DB writes happen here.
-  # 2. Without arguments — scheduled periodic sweep that flushes the current
-  #    thread's buffer (useful as a cron safety net for low-traffic apps where
-  #    the flush interval may not be reached during a request).
+  # 2. Without arguments — sweeps EVERY live thread's buffer.
   #
-  # Example cron (via solid_queue or whenever):
+  # Mode 2 is now a belt-and-braces backstop, not the primary drain. Buffers are
+  # drained at the end of each request and job by the executor hook registered in
+  # the engine (see RackAttackTracker#flush_if_due!), and again at process exit.
+  # Scheduling this job is therefore optional; it only ever finds counts on
+  # threads that are still alive but have not completed a unit of work since
+  # their deadline elapsed. It CANNOT recover counts from a thread that has
+  # already died — Thread.list does not include it.
+  #
+  # Optional cron (via solid_queue or whenever):
   #   every 5.minutes { RailsErrorDashboard::RackAttackFlushJob.perform_later }
   class RackAttackFlushJob < ApplicationJob
     queue_as :default

data/lib/rails_error_dashboard/configuration.rb

@@ -205,7 +205,7 @@ module RailsErrorDashboard
     # their own table, independent of error capture (breadcrumbs optional).
     attr_accessor :enable_rack_attack_tracking          # Master switch (default: false)
     attr_accessor :rack_attack_max_cache_size           # Max buffered keys per thread (default: 1000)
-    attr_accessor :rack_attack_flush_interval           # Seconds between DB flushes (default: 60)
+    attr_accessor :rack_attack_flush_interval           # Seconds between DB flushes (default: 5)
 
     # ActionCable event tracking (requires enable_breadcrumbs = true)
     attr_accessor :enable_actioncable_tracking          # Master switch (default: false)
@@ -429,7 +429,12 @@ module RailsErrorDashboard
       # Persists to its own table; does NOT require breadcrumbs.
       @enable_rack_attack_tracking = false
       @rack_attack_max_cache_size = 1000 # Max buffered keys per thread (LRU eviction)
-      @rack_attack_flush_interval = 60   # Seconds between DB flushes
+      # Max age of buffered events before they are written out. Lowered from 60
+      # to 5 alongside the end-of-request drain (issue #170): the executor hook
+      # gates on this interval, so it is the upper bound on how stale the Rate
+      # Limits page can be, not a per-request cost. A flood still collapses to
+      # roughly one write per thread per interval.
+      @rack_attack_flush_interval = 5    # Seconds between DB flushes
 
       # ActionCable event tracking defaults - OFF by default (opt-in, requires breadcrumbs)
       @enable_actioncable_tracking = false
@@ -628,7 +633,7 @@ module RailsErrorDashboard
         # Rack::Attack initializer has loaded, so a missing constant here does
         # not prove it will still be missing at after_initialize (when the
         # subscriber actually registers). Auto-disabling would break that case.
-        unless defined?(::Rack::Attack)
+        unless rack_attack_defined?
           warnings << "enable_rack_attack_tracking is enabled but the rack-attack gem " \
                       "does not appear to be loaded. No events will be recorded until " \
                       "Rack::Attack is installed and configured."
@@ -1033,6 +1038,14 @@ module RailsErrorDashboard
 
     # Detect where the engine is mounted in the host app's routes.
     # @return [String] mount path (default: "/red")
+    # Extracted so specs can simulate the gem's absence. rack-attack is in the
+    # dev bundle (so specs can drive the real middleware), which means
+    # ::Rack::Attack is always defined during the suite and absence can no
+    # longer be produced by simply not requiring it.
+    def rack_attack_defined?
+      defined?(::Rack::Attack) ? true : false
+    end
+
     def detect_engine_mount_path
       return "/red" unless defined?(Rails) && Rails.application
 

data/lib/rails_error_dashboard/engine.rb

@@ -86,6 +86,21 @@ module RailsErrorDashboard
          defined?(Rack::Attack)
         RailsErrorDashboard::Subscribers::RackAttackSubscriber.subscribe!
 
+        # Drain buffered counts at the end of every request and job.
+        #
+        # Without this the buffer is only ever drained by a LATER event arriving
+        # on the SAME thread (see RackAttackTracker#flush_if_due!), so a rule that
+        # matches once stays invisible until the process exits, and counts on a
+        # Puma thread that retires are lost outright rather than delayed.
+        #
+        # to_complete fires after the response body is closed, so the client
+        # already has its bytes — this never delays a request (safety rule 2).
+        # It also fires when the app raised, and is re-entrant, so nested
+        # executor blocks do not double-flush.
+        Rails.application.executor.to_complete do
+          RailsErrorDashboard::Services::RackAttackTracker.flush_if_due!
+        end
+
         # Buffered counts live on the Puma threads that served the requests and
         # are only written out on the flush interval, which a low-traffic rule
         # may never reach. Without this, everything still buffered at SIGTERM

data/lib/rails_error_dashboard/services/ai_agent_classifier.rb

@@ -31,7 +31,26 @@ module RailsErrorDashboard
         "Claude-User" => /Claude-User/i,
         "Claude Code" => /Claude-?Code/i,
         "Perplexity-User" => /Perplexity-User/i,
-        "Gemini-User" => /Gemini-User/i
+        "Gemini-User" => /Gemini-User/i,
+        # Observed in production traffic by the reporter of #170:
+        # "GitHubCopilotRuntime-WebFetch", 7 requests from 5 IPs. Classified as
+        # an assistant rather than a crawler because it fetches a specific URL a
+        # developer's Copilot session asked for, one page at a time — not a bulk
+        # corpus crawl.
+        #
+        # The pattern is deliberately anchored on "GitHubCopilot" rather than a
+        # bare /Copilot/i. Microsoft applies the Copilot brand very broadly, and
+        # its Copilot features are documented as riding Bingbot infrastructure or
+        # sending ordinary Edge/Chromium user agents with no bot signal — so a
+        # loose pattern would mislabel plain browser traffic as an AI agent,
+        # which is exactly the wrong-attribution failure this class avoids.
+        #
+        # No authoritative UA documentation exists for this agent: it is absent
+        # from GitHub's own docs, from ai-robots-txt/ai.robots.txt, and from the
+        # Dark Visitors catalogue as of 2026-08-29. The pattern therefore matches
+        # only what has actually been observed, plus the "-WebFetch" sibling
+        # suffix, instead of guessing at variants.
+        "GitHub Copilot" => /GitHubCopilot/i
       }.freeze
 
       AI_CRAWLERS = {

data/lib/rails_error_dashboard/services/rack_attack_tracker.rb

@@ -24,7 +24,23 @@ module RailsErrorDashboard
     # - Async flush via background job
     class RackAttackTracker
       COUNTS_THREAD_KEY = :red_rack_attack_counts
-      FLUSH_THREAD_KEY  = :red_rack_attack_last_flush
+
+      # Monotonic timestamp of the moment the buffer became non-empty — the
+      # DEADLINE clock, not a "last flush" clock.
+      #
+      # WHY THE DISTINCTION MATTERS: this used to hold the last flush time and be
+      # seeded lazily inside maybe_flush! with `||= now`, which meant the very
+      # first event of a buffer set the clock to now and then compared `now - now
+      # >= interval` — false, always. A rule that matched once and never again
+      # therefore never flushed at all, and a manual `curl` test showed an empty
+      # table indefinitely (issue #170, third report). Seeding when the buffer
+      # STARTS filling makes the guarantee "buffered data is never older than
+      # flush_interval", which is the property the dashboard actually needs.
+      DEADLINE_THREAD_KEY = :red_rack_attack_deadline_at
+
+      # Kept as an alias so a host or spec holding the old key name still clears
+      # the right slot. Both are cleared together in reset!.
+      FLUSH_THREAD_KEY = :red_rack_attack_last_flush
 
       # Field length caps — must match the column limits in the migration so that
       # truncation happens before the value ever reaches the unique upsert index.
@@ -38,6 +54,10 @@ module RailsErrorDashboard
       # eviction. Without this the evicted count vanishes silently and the
       # dashboard under-reports with no indication anything was lost — the same
       # problem StormProtection::CountBuffer solves with an overflow counter.
+      # Fallback when configuration is unreadable. Must match
+      # Configuration#rack_attack_flush_interval's default.
+      DEFAULT_FLUSH_INTERVAL = 5
+
       OVERFLOW_RULE       = "__overflow__"
       OVERFLOW_MATCH_TYPE = "overflow"
 
@@ -69,6 +89,13 @@ module RailsErrorDashboard
           )
 
           counts = (Thread.current[COUNTS_THREAD_KEY] ||= {})
+
+          # Start the deadline the moment the buffer goes from empty to non-empty.
+          # Doing it here (rather than lazily at flush-check time) is what makes
+          # "never older than flush_interval" true for a buffer that receives
+          # exactly one event and then goes quiet.
+          Thread.current[DEADLINE_THREAD_KEY] ||= monotonic_now if counts.empty?
+
           counts[key] = (counts[key] || 0) + 1
 
           # LRU eviction — bounds memory under rotating-discriminator attacks.
@@ -98,7 +125,11 @@ module RailsErrorDashboard
 
           snapshot = counts.dup
           counts.clear
-          Thread.current[FLUSH_THREAD_KEY] = Time.now.to_f
+          # Buffer is empty again, so there is nothing to be late: clear the
+          # deadline. The next record! reseeds it. Leaving a stale timestamp
+          # here would make the very next event look instantly overdue.
+          Thread.current[DEADLINE_THREAD_KEY] = nil
+          Thread.current[FLUSH_THREAD_KEY] = nil
 
           dispatch_flush(snapshot, sync: sync)
           nil
@@ -132,6 +163,7 @@ module RailsErrorDashboard
 
               snapshot = counts.dup
               counts.clear
+              thread[DEADLINE_THREAD_KEY] = nil
               thread[FLUSH_THREAD_KEY] = nil
 
               dispatch_flush(snapshot, sync: true)
@@ -149,10 +181,51 @@ module RailsErrorDashboard
           nil
         end
 
+        # Drain this thread's buffer at the end of a unit of work (a request or a
+        # job), if it has been waiting longer than flush_interval.
+        #
+        # WHY THIS EXISTS (issue #170, third report): before this, the ONLY
+        # in-process drain was maybe_flush! inside record, so the buffer could
+        # only ever be flushed by a LATER event landing on the SAME thread. Two
+        # consequences, both reported as "no events are recorded at all":
+        #
+        #   1. A rule that matched once showed nothing until the process exited.
+        #      `curl` once, look at the dashboard, see an empty table — forever.
+        #   2. Worse, Puma reuses and retires threads. Counts buffered on a thread
+        #      that dies are unreachable to flush_all_threads! (it walks
+        #      Thread.list), so they were lost outright, not merely delayed.
+        #      Measured: 5 of 5 events lost when the serving threads exited.
+        #
+        # ActiveSupport::Executor#to_complete is the right boundary because Rails
+        # already guarantees it runs once per request and once per job. Crucially,
+        # ActionDispatch::Executor returns a Rack::BodyProxy and defers the hook
+        # until the SERVER CLOSES THE RESPONSE BODY — so this runs after the client
+        # has its bytes and cannot delay the response (safety rule 2).
+        #
+        # The flush is gated on flush_due?, so a flood does not turn into one
+        # UPDATE per request — the exact regression #143's buffer exists to
+        # prevent. Measured 0.068 ms/req gated vs 0.508 ms/req ungated.
+        def flush_if_due!
+          return unless enabled?
+          return unless flush_due?
+
+          # sync: the response is already sent, so there is nothing left to block,
+          # and enqueueing a job per interval would be more overhead than the
+          # single upsert it replaces.
+          flush!(sync: true)
+          nil
+        rescue => e
+          RailsErrorDashboard::Logger.debug(
+            "[RailsErrorDashboard] RackAttackTracker.flush_if_due! failed: #{e.class} - #{e.message}"
+          )
+          nil
+        end
+
         # Clear thread-local state without persisting. Used by specs and by
         # thread teardown paths.
         def reset!
           Thread.current[COUNTS_THREAD_KEY] = nil
+          Thread.current[DEADLINE_THREAD_KEY] = nil
           Thread.current[FLUSH_THREAD_KEY] = nil
           nil
         rescue => e
@@ -179,6 +252,24 @@ module RailsErrorDashboard
           parts.fill("", parts.length, 6 - parts.length)
         end
 
+        # Cheap deadline check — a float subtraction, no I/O.
+        #
+        # Returns true when the buffer has been waiting at least flush_interval.
+        # Uses a monotonic clock: Time.now can jump backwards (NTP correction,
+        # leap second) and would then defer the flush indefinitely.
+        def flush_due?
+          deadline = Thread.current[DEADLINE_THREAD_KEY]
+          return false if deadline.nil?
+
+          (monotonic_now - deadline) >= flush_interval
+        rescue => e
+          false
+        end
+
+        def monotonic_now
+          Process.clock_gettime(Process::CLOCK_MONOTONIC)
+        end
+
         private
 
         def enabled?
@@ -215,13 +306,9 @@ module RailsErrorDashboard
           )
         end
 
-        # Cheap periodic flush check — a float subtraction, no I/O.
+        # Cheap periodic flush check on the record path — no I/O.
         def maybe_flush!
-          now = Time.now.to_f
-          last_flush = Thread.current[FLUSH_THREAD_KEY] ||= now
-          return unless (now - last_flush) >= flush_interval
-
-          flush!
+          flush! if flush_due?
         end
 
         # Dispatch asynchronously so the request path never waits on the DB.
@@ -257,9 +344,9 @@ module RailsErrorDashboard
         end
 
         def flush_interval
-          RailsErrorDashboard.configuration.rack_attack_flush_interval || 60
+          RailsErrorDashboard.configuration.rack_attack_flush_interval || DEFAULT_FLUSH_INTERVAL
         rescue => e
-          60
+          DEFAULT_FLUSH_INTERVAL
         end
 
         # Truncate to the column limit and strip the key separator. A rule name

data/lib/rails_error_dashboard/version.rb

@@ -1,3 +1,3 @@
 module RailsErrorDashboard
-  VERSION = "0.11.1"
+  VERSION = "0.11.3"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: rails_error_dashboard
 version: !ruby/object:Gem::Version
-  version: 0.11.1
+  version: 0.11.3
 platform: ruby
 authors:
 - Anjan Jagirdar
@@ -219,24 +219,43 @@ dependencies:
     - - "~>"
       - !ruby/object:Gem::Version
         version: '0.15'
-description: 'Rails Error Dashboard (RED) is an open-source, self-hosted Rails engine
-  for investigating production exceptions without sending error data to a monitoring
+description: |
+  == Rails-native failure investigation
+
+  Rails Error Dashboard (RED) is an open-source, self-hosted Rails engine for
+  investigating production exceptions without sending error data to a monitoring
   vendor. It groups errors and records request context and cause chains and, when
-  enabled, breadcrumbs plus local and instance variables captured before Ruby unwinds
-  the stack. RED attaches Rails and Ruby runtime health to the error record on every
-  captured occurrence, including Active Record pool, Puma, background jobs, GC, memory,
-  threads, file descriptors and system pressure. Built-in storm protection progressively
-  sheds expensive context and I/O during error floods while retaining useful exemplars
-  and exact occurrence counts. Run RED with your application''s database or an isolated
-  error database. It supports PostgreSQL, MySQL/Trilogy and SQLite, and includes workflow,
-  notifications (Slack, Email, Discord, PagerDuty, webhooks), two-way issue sync with
-  GitHub, GitLab, Codeberg and Linear, Copy as RSpec/curl/LLM, swallowed-exception
-  detection, LLM observability without prompt capture, OpenTelemetry span export and
-  Rails-specific operational views. The dashboard is translated into 11 languages
-  (machine-translated outside English, awaiting native review). A self-hosted Sentry
-  alternative that keeps error data in your own database. The gem is MIT and free
-  forever. Supports Rails 7.0-8.1 and Ruby 3.2-4.0. Beta: APIs may change before 1.0.
-  Live demo: https://rails-error-dashboard.anjan.dev'
+  enabled, breadcrumbs plus local and instance variables captured before Ruby
+  unwinds the stack.
+
+  == What it records
+
+  * Rails and Ruby runtime health on the error record, refreshed on every captured
+    occurrence: Active Record pool, Puma, background jobs, GC, memory, threads,
+    file descriptors and system pressure
+  * Built-in storm protection that progressively sheds expensive context and I/O
+    during error floods while retaining useful exemplars and exact occurrence
+    counts
+  * Copy as RSpec, curl or LLM prompt; swallowed-exception detection; LLM
+    observability without prompt capture; OpenTelemetry span export
+  * Workflow, notifications (Slack, Email, Discord, PagerDuty, webhooks) and
+    two-way issue sync with GitHub, GitLab, Codeberg and Linear
+  * Rails-specific operational views: jobs, database, cache, Action Cable, Active
+    Storage, Rack::Attack and deprecations
+
+  == Running it
+
+  Run RED with your application's database or an isolated error database, on
+  PostgreSQL, MySQL/Trilogy or SQLite. The dashboard is translated into 11
+  languages (machine-translated outside English, awaiting native review). A
+  self-hosted Sentry alternative that keeps error data in your own database. The
+  gem is MIT and free forever.
+
+  Supports Rails 7.0-8.1 and Ruby 3.2-4.0. Beta: APIs may change before 1.0.
+
+  Live demo: https://rails-error-dashboard.anjan.dev
+
+  Documentation: https://AnjanJ.github.io/rails_error_dashboard
 email:
 - anjan.jagirdar@gmail.com
 executables: []
@@ -556,7 +575,7 @@ metadata:
   funding_uri: https://github.com/sponsors/AnjanJ
 post_install_message: |
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-    RED (Rails Error Dashboard) v0.11.1
+    RED (Rails Error Dashboard) v0.11.3
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
   First install: