railwatch 0.3.6 → 0.3.7

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 7670085bcbae37c58def37c8e23ffee964be9277a57462869346017016c33a3c
-  data.tar.gz: fb68d72c0863778eb607cfd2bded53714651caaecffefbff20994e25422a1411
+  metadata.gz: 56eb44eab9d0988d36c517995ad2ec8d42971ed9af60e3cf4c419c5df926007f
+  data.tar.gz: 20f9bfed5d8044797a1e43b523668846b2b888756ff9fef59a1f54dc136d64c1
 SHA512:
-  metadata.gz: 429bb5789a56059dce9848403622511df0f5094c2efe4a6ed8c51e5086fb11eaf56b8c762ee9ae68d1ae393a5fae7af65d628df019f01b00466644e207aa6b1d
-  data.tar.gz: 0c38280c362f3529ca2af1e93a6982d77ed15a872351072727dd1152396ea2c3f1a2e634f1132a6cac83bf0ee152f818fda15db76e2251a3f0f1a7a24db5bfb1
+  metadata.gz: 8bbd22e4636c6c3ba58dfff0242d3553db415af9b90041b524634ae7b95e65a0ff52f6584c7d6c4c61aee12274e177b308d06040508db41ee8db0af81ff1ab0d
+  data.tar.gz: 398eea6fd06b824600b834f5da026f68b70fba6a5bcc1ec97c73995933ca9a8e569cca0d5135f27ee413563281bd91a941eb19ccb954f0b731cd25b2446ba86c

data/CHANGELOG.md

@@ -1,5 +1,33 @@
 # Changelog
 
+## 0.3.7 (2026-09-20)
+
+- Stop a rake task or `rails runner` waiting on the network as it finishes.
+  The command patches called `Railwatch.flush` when the execution closed --
+  on the application's own thread, with no time limit. The engine's `at_exit`
+  already calls `Reporter#shutdown`, which wakes the reporter thread and joins
+  it for `shutdown_timeout`, so the same records were already being delivered,
+  already bounded, and a failed task's exception already went with them. The
+  flush was a second, unbounded way to do it.
+
+  Against a receiver that accepts connections and never answers, that second
+  way cost a full timeout ladder per process -- measured at ~6s, and ~12s when
+  it queued behind a delivery the reporter thread was already stuck in. An app
+  whose container entrypoint boots Rails eleven times before starting Puma
+  spent that on every boot and lost the deploy to its proxy's timeout. With
+  the call removed the task returns immediately and the process still leaves
+  within `shutdown_timeout`, carrying the same records.
+
+  Only short-lived processes were affected: web and worker processes flush on
+  the reporter's own thread and never blocked. `Railwatch.flush` is unchanged
+  and still public, for a caller who wants to wait on purpose.
+
+- Add a process-level regression that runs a failing rake task against a
+  socket that accepts and never answers, and asserts the task returns without
+  waiting on it and the process exits inside the shutdown bound. In-process
+  examples cannot see this: the cost lives in a socket read and the bound in
+  an `at_exit` join.
+
 ## 0.3.6 (2026-09-20)
 
 - Harden embedded live-stream authorization and telemetry delivery. Bound

data/docs/configuration.md

@@ -431,9 +431,14 @@ affects one probabilistic decision. Set `backpressure` false to keep the
 factor at 1. The current value is sent as
 `X-Railwatch-Backpressure-Factor` whenever it is greater than 1.
 
-`Railwatch.flush` forces an immediate flush. The `command` patches also
-call it after a rake task/runner invocation finishes, so short-lived
-processes don't lose their last batch to the flush interval. An unhandled
+`Railwatch.flush` forces an immediate flush, on the calling thread and
+without a time limit, so it is yours to call when you know you want to
+wait. Nothing in the gem calls it for you: a short-lived process keeps its
+last batch because the engine's `at_exit` runs `Reporter#shutdown`, which
+wakes the reporter thread and joins it for `shutdown_timeout`. That is a
+bounded wait, which is what a rake task, a runner or a cron job needs --
+a receiver that accepts connections and never answers then costs
+`shutdown_timeout`, not a timeout ladder per process. An unhandled
 exception goes through `Railwatch.record_now` → `Reporter#write_now`,
 which enqueues the record and asks for an urgent flush. It never performs
 network I/O or a timeout cycle on the application thread. Urgent means

data/lib/railwatch/patches/rake_task.rb

@@ -72,7 +72,16 @@ module Railwatch
             name: name,
             command: "rake #{name}#{command_suffix}",
             exit_code: exit_code.to_i.clamp(0, 255))
-          Railwatch.flush
+          # Deliberately no flush. The engine's at_exit calls Reporter#shutdown,
+          # which wakes the reporter thread and joins it for shutdown_timeout --
+          # already a bounded last delivery, and already the one that ships a
+          # failed task's exception. Flushing here as well delivered the same
+          # records a second way, on the application's own thread, with no
+          # bound: against a receiver that accepts connections and never
+          # answers it cost a full timeout ladder per process, measured at ~6s,
+          # and ~12s when it queued behind a delivery the reporter thread was
+          # already stuck in. An app whose entrypoint boots Rails eleven times
+          # spent that eleven times over and lost the deploy.
         end
       end
 

data/lib/railwatch/patches/runner_command.rb

@@ -91,7 +91,9 @@ module Railwatch
           }
           fields[:interactive] = true if interactive
           Railwatch.finish_execution(:command, **fields)
-          Railwatch.flush
+          # No flush here either; see the note in patches/rake_task.rb. The
+          # at_exit shutdown is the bounded delivery, and it runs for a runner
+          # exactly as it does for a task.
         end
       end
 

data/lib/railwatch/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Railwatch
-  VERSION = "0.3.6"
+  VERSION = "0.3.7"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: railwatch
 version: !ruby/object:Gem::Version
-  version: 0.3.6
+  version: 0.3.7
 platform: ruby
 authors:
 - Cole Robertson