rage-rb 1.23.0 → 1.25.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bbc12eab5d13d5570107f5c7bf6d0b68f6f652eccc1eaafefdb47ef92ed3b264
-  data.tar.gz: 7adca2c0e96d38ca69c32f4fc12b03984b6aa46578d48d084645e11891915e99
+  metadata.gz: 177c149ab02c459e231c8853a303f23da977767073611fa1996e3e9b4f3ebd7c
+  data.tar.gz: a28617f5ea6d85f95eb0d900582dddacf2fb83f8190f31e46f84700419ccfdc2
 SHA512:
-  metadata.gz: cb010618b1afebee5baa5fee44963d8cdf4f1543769b79ee81d26e9a0815c3ea59d6b0cf4dad2f53adabbe8d26ae0688876d2a0f690e1497173469446ba4a9e8
-  data.tar.gz: ee292c1c8b93fed32dbe015e6de898df1f0bb63ede69deb2b1eb41cddee1e339ade19ed8981682697721b02c3923bb8782358616c5d7c264cc0d465887b6e79b
+  metadata.gz: d1c422f7d8755b56a88203f5669d36d518a1ff69a9bc2fc9e8fbd9e0b628fc25884c44615bfbc7f577e3519e9be3c5499dc4cf7fd136065e6292e95fe1833635
+  data.tar.gz: 10a7692229b832f1eeb540114835c9ac49a317372e796163c3be7eb8d3d906cf89e9e3cd18c033e61834fa8dc192f1dbfc3a25f509f0a6c7496b0be8dcb4e026

data/CHANGELOG.md

@@ -1,5 +1,43 @@
 ## [Unreleased]
 
+## [1.25.0] - 2026-06-03
+
+### Added
+
+- Implement `FiberScheduler#fiber_interrupt` (#283).
+- [OpenAPI] Add Blueprinter parser scaffold and class detection (#287)
+- [OpenAPI] Extend @response / @request tag syntax to accept serializer options (#299)
+- Add `FiberScheduler#blocking_operation_wait` (#303).
+- [OpenAPI] Added static parsing of basic Blueprinter fields (`identifier`, `field`, `fields`) for OpenAPI schema generation. (#289)
+
+### Fixed
+
+- [API] Reject malformed or empty HTTP token authorization headers.
+- [Cookies] Strip the port from `HTTP_HOST` before matching configured cookie domains.
+- [Router] Strip the port from `HTTP_HOST` before matching exact host constraints.
+
+## [1.24.0] - 2026-05-12
+
+### Added
+
+- [Deferred] Add tests for log context capture and backward-compatible restore by [@jsxs0](https://github.com/jsxs0) (#274).
+- [OpenAPI] Add support for per-endpoint OAuth2/OpenID scopes via `@auth_scope` tag by [@Piyush-Goenka](https://github.com/Piyush-Goenka) (#272).
+- Reuse `define_dynamic_method` and `define_maybe_yield` methods in `RageController::API` from `Rage::Internal` by [@numice](https://github.com/numice) (#273).
+- Add the `form_actions` router configuration (#278).
+- [Deferred] Add native periodic task scheduling with multi-process leader election via `File#flock` by [@Abishekcs](https://github.com/Abishekcs) (#233).
+- [OpenAPI] Support optional attributes and `Array<>` syntax by [@ayushman1210](https://github.com/ayushman1210) (#228).
+- [Errors] Add centralized error reporting interface via `Rage.errors` and `config.error_handlers` by [@Digvijay-x1](https://github.com/Digvijay-x1) (#275).
+
+### Fixed
+
+- [OpenAPI] Fix SystemStackError in Alba parser with circular associations (#268).
+- Rewind `rack.input` when parsing request body (#279).
+
+### Changed
+
+- [Deferred] Increase default retry limit to 20 and update default retry backoff to `(attempt**4) + 10 + (rand(15) * attempt)` by  [@anuj-pal27](https://github.com/anuj-pal27) (#271).
+- Update `Rage::Cable` to use the new `PubSub` module (#281).
+
 ## [1.23.0] - 2026-04-15
 
 ### Fixed

data/CONTRIBUTING.md

@@ -0,0 +1,240 @@
+# Contributing to Rage
+
+This guide is designed to help contributors understand the project's internals, design principles, and conventions. Whether you're fixing a bug, adding a feature, or participating in GSoC, this document will help you get started.
+
+## Table of Contents
+
+- [Design Principles](#design-principles)
+- [Documentation Standards](#documentation-standards)
+- [Dynamic Code Generation](#dynamic-code-generation)
+- [Iodine Integration](#iodine-integration)
+- [The Fiber Runtime](#the-fiber-runtime)
+- [A Note on AI Usage](#a-note-on-ai-usage)
+
+## Design Principles
+
+### Performance Over Readability
+
+Rage is a framework, not application code. While readability matters, performance takes priority when the two conflict. Framework code runs on every request, so micro-optimizations compound into significant gains.
+
+This doesn't mean writing deliberately obscure code. It means accepting that some patterns which would be discouraged in application code are acceptable here when they improve performance.
+
+### Lean Happy Path
+
+The happy path should execute as little code as possible. We achieve this through:
+
+1. **Boot-time computation**: Move work to server startup whenever possible. Pre-compile routes, resolve callback chains, and build method definitions during initialization rather than on each request.
+
+2. **Feature isolation**: New features should not impact performance for users who don't use them. If a feature requires runtime checks, consider whether those checks can be eliminated through code generation or configuration.
+
+### Duplication Over Premature Abstraction
+
+Duplication is cheaper than unnecessary abstraction.
+
+Abstractions should emerge from observed patterns, not anticipated ones. When you see similar code in two places, resist the urge to immediately extract a helper. Introducing new abstraction layers or deduplicating code should only happen after the duplication has naturally occurred and proven to be a burden.
+
+A wrong abstraction is worse than duplicated code because:
+- It's harder to understand (you must trace through multiple layers)
+- It's harder to modify (changes affect all call sites)
+- It's harder to remove (it becomes load-bearing)
+
+When you do introduce an abstraction, make sure it pulls its weight.
+
+## Documentation Standards
+
+### YARD Documentation
+
+All user-facing methods must be documented using [YARD](https://yardoc.org/). Documentation comments use Markdown formatting.
+
+```ruby
+# Publish an event to all registered subscribers.
+#
+# @param event [Object] the event instance to publish
+# @param context [Hash] optional context to pass to subscribers
+# @return [void]
+#
+# @example Publishing an event
+#   Rage::Events.publish(OrderCreated.new(order: order))
+#
+# @example Publishing with context
+#   Rage::Events.publish(OrderCreated.new(order: order), context: { user_id: current_user.id })
+#
+def publish(event, context: nil)
+  # ...
+end
+```
+
+### The `@private` Tag
+
+Some methods cannot be marked `private` using Ruby's `private` keyword (e.g., they need to be called from other classes within the framework), but they are not part of the public API. These methods should be marked with the `@private` YARD tag:
+
+```ruby
+# @private
+# Used internally by the router to register controller actions.
+def __register_action(action)
+  # ...
+end
+```
+
+The `@private` tag signals to contributors:
+- This method is not part of the user-facing API
+- It can be modified or removed without deprecation
+- It can be used freely within the framework codebase
+
+## Dynamic Code Generation
+
+Rage relies heavily on dynamic code generation for both performance and flexibility. Understanding this pattern is essential for contributing to the framework.
+
+### Why Dynamic Code Generation?
+
+1. **Performance**: Generated code avoids runtime conditionals. Instead of checking "does this controller have before actions?" on every request, we generate a method that either includes the before action calls or doesn't.
+
+2. **Flexibility**: Generated code can adapt to user-defined signatures, allowing optional parameters without forcing users to accept arguments they don't need.
+
+### Examples in the Codebase
+
+#### Controller Action Registration
+
+`RageController::API.__register_action` (in `lib/rage/controller/api.rb`) generates a method for each controller action at boot time:
+
+```ruby
+class_eval <<~RUBY, __FILE__, __LINE__ + 1
+  def __run_#{action}
+    #{before_actions_chunk}
+    #{action} unless @__before_callback_rendered
+    #{after_actions_chunk}
+    [@__status, @__headers, @__body]
+    #{rescue_handlers_chunk}
+  end
+RUBY
+```
+
+This generates a single method that includes only the callbacks and exception handlers relevant to that specific action. No runtime resolution required.
+
+#### Logger Rebuilding
+
+`Rage::Logger#rebuild!` (in `lib/rage/logger/logger.rb`) generates logging methods based on the configured log level:
+
+```ruby
+if level_val < @level
+  # Log level is filtered out - generate a no-op method
+  def info(msg = nil, context = nil)
+    false
+  end
+else
+  # Generate a method that actually logs
+  def info(msg = nil, context = nil)
+    # ... logging implementation
+  end
+end
+```
+
+When logging at a level is disabled, the method becomes a no-op with zero overhead.
+
+#### Telemetry Tracer
+
+`Rage::Telemetry::Tracer#setup` (in `lib/rage/telemetry/tracer.rb`) generates tracing methods that call only the handlers registered for each span. If no handlers are registered, it generates a pass-through method.
+
+### Dynamic Keyword Arguments
+
+One pattern Rage uses extensively is dynamic keyword arguments. This allows users to define methods that accept only the parameters they care about, without requiring `**` to absorb extras.
+
+For example, an event subscriber can be defined either way:
+
+```ruby
+# Subscriber that only cares about the event
+def call(event)
+end
+
+# Subscriber that also needs context
+def call(event, context:)
+end
+```
+
+Both work regardless of whether the event was published with context. The framework inspects the method signature and generates a call that passes only the expected arguments.
+
+The `Rage::Internal.build_arguments` method (in `lib/rage/internal.rb`) implements this pattern:
+
+```ruby
+def build_arguments(method, arguments)
+  expected_parameters = method.parameters
+
+  arguments.filter_map { |arg_name, arg_value|
+    if expected_parameters.any? { |param_type, param_name| param_name == arg_name || param_type == :keyrest }
+      "#{arg_name}: #{arg_value}"
+    end
+  }.join(", ")
+end
+```
+
+This inspects the target method's parameters and generates a string containing only the arguments that method expects. The generated string is then embedded into dynamically defined code.
+
+This pattern appears in:
+- Event subscribers (accepting event with optional context)
+- Telemetry handlers (accepting various span attributes)
+- External loggers (accepting severity, message, context, etc.)
+
+## Iodine Integration
+
+Rage consists of two components: the framework (this repository) and its server, [Iodine](https://github.com/rage-rb/iodine). Iodine is not an external dependency; it's part of the Rage runtime, and its methods can be used freely within the codebase.
+
+### Useful Iodine Methods
+
+**`Iodine.run_after(milliseconds) { ... }`**: Schedule a block to run after a delay.
+
+```ruby
+Iodine.run_after(5000) do
+  cleanup_expired_sessions
+end
+```
+
+**`Iodine.run_every(milliseconds) { ... }`**: Schedule a block to run at regular intervals.
+
+```ruby
+Iodine.run_every(60_000) do
+  report_metrics
+end
+```
+
+**`Iodine.publish(channel, message, engine)`**: Send a message to subscribers. This is used for inter-fiber and inter-process communication.
+
+```ruby
+# Notify within the current process
+Iodine.publish("my_channel", "message", Iodine::PubSub::PROCESS)
+
+# Notify across all processes in the cluster
+Iodine.publish("my_channel", "message", Iodine::PubSub::CLUSTER)
+```
+
+**`Iodine.on_state(state) { ... }`**: Register callbacks for server lifecycle events.
+
+```ruby
+Iodine.on_state(:on_start) do
+  # Runs when the worker process starts
+end
+```
+
+## The Fiber Runtime
+
+### Rage::FiberWrapper
+
+`Rage::FiberWrapper` (in `lib/rage/middleware/fiber_wrapper.rb`) is the glue between the framework and the server. It sits at the top of the middleware stack and:
+
+1. Wraps every request in a Fiber
+2. Implements the defer protocol for pausing/resuming async requests
+
+When a request encounters blocking I/O (database query, HTTP request, etc.), the fiber yields. `FiberWrapper` detects this (`fiber.alive?`) and returns a special `:__http_defer__` signal to Iodine, which pauses the connection.
+
+When the I/O completes, the fiber resumes and publishes a message to notify Iodine that the response is ready. This is the mechanism that enables transparent, non-blocking concurrency.
+
+## A Note on AI Usage
+
+Contributors are free to use AI tools however they see fit.
+
+One thing to keep in mind: when delegating development to AI, the friction this removes is the very friction that enables developers to understand the system, learn, and grow as professionals.
+
+There's value in the struggle of tracing through code, understanding why something was designed a certain way, and building mental models of complex systems. Use AI to assist and accelerate, but ensure you are still engaging deeply with the architecture and the "why" behind the code you are committing.
+
+---
+
+Questions? Open an issue or reach out to the maintainers.

data/README.md

@@ -6,9 +6,9 @@
 ![Tests](https://github.com/rage-rb/rage/actions/workflows/main.yml/badge.svg)
 ![Ruby Requirement](https://img.shields.io/badge/Ruby-3.3%2B-%23f40000)
 
-**Rage** is an API-first Ruby framework with a modern, fiber-based runtime that enables transparent, non-blocking concurrency while preserving familiar developer ergonomics. It focuses on **capability and operational simplicity**, letting teams build production-grade systems in a single, coherent runtime.
+**Rage** is an API-first Ruby web framework that combines the developer experience of Rails with fiber-based concurrency. You write standard synchronous Ruby code - Rage handles the concurrency, running APIs, background jobs, and WebSockets in a single process with fewer moving parts.
 
-Rage uses Rails compatibility as a foundation and provides backend primitives optimized for a single-runtime model: background jobs that run in-process, WebSockets without external dependencies, object-oriented domain events, and automatic API documentation.
+Rage uses Rails compatibility as a foundation and provides backend primitives optimized for a single-runtime model: background jobs that run in-process, scalable WebSockets and SSE streams, object-oriented domain events, and automatic API documentation.
 
 ## Why Rage
 
@@ -24,22 +24,73 @@ In the Ruby ecosystem, these concerns typically mean more infrastructure: Redis,
 
 Rage takes a different approach: **collapse backend concerns into a single runtime** by embracing Ruby's fiber-based concurrency model. This reduces operational complexity while keeping familiar Ruby ergonomics.
 
+## Key Capabilities
+
+- **Rails Compatibility** - Familiar controller API, routing DSL, and conventions. Migrate gradually or start fresh.
+- **True Concurrency** - Fiber-based architecture handles I/O without threads, locks, or async/await syntax. Your code looks synchronous but runs concurrently.
+- **Zero-dependency WebSockets** - Action Cable-compatible real-time features that work out-of-the-box, with built-in IPC for multi-process deployments.
+- **Server-Sent Events** - Native SSE streaming with no external dependencies. Built for live feeds, progress updates, and LLM response streaming.
+- **Auto-generated OpenAPI** - Documentation generated from your controllers using simple comment tags.
+- **In-process Background Jobs** - A durable, persistent queue that runs inside your app process. No external dependencies or separate worker processes required.
+- **Built-in Observability** - Track and measure application behavior with `Rage::Telemetry`. Integrate with external monitoring platforms or build custom observability solutions.
+
+## Installation
+
+Install the gem:
+
+```
+$ gem install rage-rb
+```
+
+Create a new app:
+
+```
+$ rage new my_app
+```
+
+Switch to your new application and install dependencies:
+
+```
+$ cd my_app
+$ bundle install
+```
+
+(Optional 🤖) Install agent skills:
+
+```
+$ rage skills install
+```
+
+Start up the server and visit http://localhost:3000.
+
+```
+$ rage s
+```
+
+Start coding!
+
+## How It Works
+
+Rage runs each request in a separate fiber. When your code performs I/O operations - HTTP requests, database queries, file reads - the fiber automatically pauses, and Rage processes other requests. When the I/O completes, the fiber resumes exactly where it left off.
+
+This happens automatically. You write standard Ruby code, and Rage handles the concurrency.
+
 ### Unified Runtime in Action
 
 Here's what single runtime looks like in practice:
 
 ```ruby
 class OrdersController < RageController::API
+  # Create an order record.
+  # @request { amount: Float, product_id: Integer }
+  # @response 201 Order
   def create
     order = Order.create!(order_params)
 
     # Schedule background job - runs in-process, no Redis needed
     SendOrderConfirmation.enqueue(order.id)
 
-    # Publish domain event - subscribers execute immediately or async
-    Rage::Events.publish(OrderPlaced.new(order: order))
-
-    # Broadcast to WebSocket subscribers - no Action Cable/Redis needed
+    # Broadcast to WebSocket subscribers - built in, no external services needed
     Rage::Cable.broadcast("orders", { status: "created", order_id: order.id })
 
     render json: order, status: :created
@@ -55,22 +106,15 @@ class SendOrderConfirmation
     OrderMailer.confirmation(order).deliver
   end
 end
+```
 
-# Domain event - typed, object-oriented
-OrderPlaced = Data.define(:order)
+This all runs in a single process. No external queues, no separate worker dynos, no additional infrastructure.
 
-# Event subscriber
-class UpdateInventory
-  include Rage::Events::Subscriber
-  subscribe_to OrderPlaced
+## Two Ways to Use Rage
 
-  def call(event)
-    Inventory.decrement(event.order.items.length)
-  end
-end
-```
+**Standalone**: Create new services with `rage new`. You get a clean project structure, CLI tools, and everything needed to build production-ready APIs from scratch.
 
-This all runs in a single process. No external queues, no separate worker dynos, no Redis for pub/sub.
+**Rails Integration**: Add Rage to existing Rails applications for gradual migration. Use Rage for new endpoints or high-traffic routes while keeping the rest of your Rails app unchanged. See the [Rails Integration Guide](https://rage-rb.dev/docs/rails) for details.
 
 ## Coming from Rails?
 
@@ -83,7 +127,7 @@ You write familiar synchronous Ruby code. Rage handles the concurrency.
 **What changes:**
 
 - One deployment unit instead of API servers + worker processes
-- No Redis required for jobs or broadcasts
+- No external dependencies for jobs or broadcasts
 - Domain events as objects, not string-based notifications
 - OpenAPI specs generated automatically from your code
 
@@ -95,117 +139,16 @@ You write familiar synchronous Ruby code. Rage handles the concurrency.
 
 Think of Rage as Rails ergonomics with a runtime designed for modern API systems, where operational simplicity is a first-class concern.
 
-## Core Ideas
-
-### 1. Unified Backend Runtime
-
-Rage runs HTTP APIs, background jobs, and WebSockets in the same process by default:
-
-- No separate worker processes
-- No Redis required for jobs or broadcasts
-- One deployment unit for most applications
-
-This simplifies both local development and production setup.
-
-For high-scale scenarios, Rage supports multi-process deployments and allows Rage processes to communicate directly when needed.
-
-### 2. API-First, Rails-Compatible
-
-Rage provides a familiar Rails-like programming model with API-focused improvements:
-
-- Controllers and routing that feel like Rails
-- Active Record compatibility
-- Incremental adoption for existing Rails applications
-- OpenAPI specs auto-generated from your code
-
-Rails compatibility is the foundation. Rage builds on top of that foundation with new primitives designed for high-concurrency, API-first architectures.
-
-### 3. Built-in Asynchronous Execution
-
-Rage ships with **fiber-based, in-process background jobs**:
-
-- Zero setup - no Redis, no configuration
-- Jobs persist across restarts
-- Scheduled and executed within the same runtime using fibers for concurrency
-
-For teams that need distributed job processing, Rage works with existing solutions. But most applications can start simple and stay simple.
-
-### 4. Structured Domain Events
-
-Rage includes a built‑in event bus designed for **object‑oriented domain events**:
-
-* Events are classes with explicit attributes, not hashes or strings
-* Subscribers listen to event classes or mixins
-* Type-safe and refactorable
-
-This encourages clear domain modeling and avoids the brittleness of string-based notification systems.
-
-### 5. Observability by Design
-
-Observability is not an afterthought:
-
-- Structured logging by default
-- Dedicated observability interface for HTTP, background, and real-time features
-- OpenAPI specifications generated automatically from the running application
-
-API contracts stay in sync with code by default - no separate documentation pipelines.
-
-### 6. Performance That Enables Simplicity
-
-Rage's fiber-based concurrency delivers strong performance for I/O-heavy workloads, but performance is a means to an end: operational simplicity.
-
-By handling concurrency efficiently, Rage lets you:
-
-- Run fewer servers
-- Deploy fewer services
-- Reduce infrastructure by handling workloads that traditionally required separate microservices
-
-The goal is to let teams write maintainable Ruby code while natively handling massive concurrency, eliminating the need for premature optimization or infrastructure sprawl.
-
-## Philosophy
-
-Rage is intentionally conservative about change.
-
-The framework prioritizes:
-
-- **Stable public APIs**
-- **Long deprecation cycles**
-- **Minimal external dependencies**
-
-The goal is to let teams build systems that **age well** - without constant rewrites or growing infrastructure complexity.
-
-Our aspiration: the task "Upgrade Rage" never appears in your ticketing system. Most updates should be as simple as `bundle update`.
-
-## What Rage Is (and Isn't)
-
-**Rage is:**
-
-- Focused on backend APIs
-- Opinionated about operational simplicity
-- Designed for long-term stability
-- Rails-compatible but architecturally independent
-
-**Rage is not:**
-
-- A full-stack framework - no view layer, no asset pipeline
-- A Rails clone - compatibility is a bridge, not the destination
-- Trying to do everything - deliberate scope boundaries
-
-## Who Rage Is For
-
-Rage is a good fit if you:
+## Stability
 
-- Build API-only backends in Ruby
-- Care about operational simplicity over maximum flexibility
-- Want fewer moving parts in production
-- Prefer explicit, object-oriented design
-- Value long-term stability over cutting-edge features
+Rage prioritizes stable public APIs, long deprecation cycles, and minimal external dependencies. Our aspiration: the task "Upgrade Rage" never appears in your ticketing system. Most updates should be as simple as `bundle update`.
 
 ## Learn More
 
 - Documentation: [https://rage-rb.dev](https://rage-rb.dev/docs/intro)
 - API Reference: [https://rage-rb.dev/api](https://rage-rb.dev/api)
 - Architecture: [ARCHITECTURE.md](https://github.com/rage-rb/rage/blob/main/ARCHITECTURE.md)
+- Contributing: [CONTRIBUTING.md](https://github.com/rage-rb/rage/blob/main/CONTRIBUTING.md)
 
 Contributions and thoughtful feedback are welcome.
 

data/lib/rage/application.rb

@@ -23,6 +23,7 @@ class Rage::Application
     response = @exception_app.call(400, e)
 
   rescue Exception => e
+    Rage::Errors.report(e)
     response = @exception_app.call(500, e)
 
   ensure

data/lib/rage/cable/cable.rb

@@ -29,6 +29,9 @@
 # ```
 #
 module Rage::Cable
+  PUBSUB_BROADCASTER_ID = "cable"
+  private_constant :PUBSUB_BROADCASTER_ID
+
   # Create a new Cable application.
   #
   # @example
@@ -36,9 +39,6 @@ module Rage::Cable
   #     run Rage.cable.application
   #   end
   def self.application
-    # explicitly initialize the adapter
-    __adapter
-
     handler = __build_handler(__protocol)
     accept_response = [0, __protocol.protocol_definition, []]
 
@@ -61,6 +61,14 @@ module Rage::Cable
     chain
   end
 
+  # @private
+  def self.__initialize
+    if (adapter = Rage.config.pubsub.adapter)
+      adapter.add_broadcaster(PUBSUB_BROADCASTER_ID, __protocol)
+      @__adapter = adapter
+    end
+  end
+
   # @private
   def self.__router
     @__router ||= Router.new
@@ -71,11 +79,6 @@ module Rage::Cable
     @__protocol ||= Rage.config.cable.protocol.tap { |protocol| protocol.init(__router) }
   end
 
-  # @private
-  def self.__adapter
-    @__adapter ||= Rage.config.cable.adapter
-  end
-
   # @private
   def self.__build_handler(protocol)
     klass = Class.new do
@@ -125,7 +128,8 @@ module Rage::Cable
       end
 
       def log_error(e)
-        Rage.logger.error("Unhandled exception has occured - #{e.class} (#{e.message}):\n#{e.backtrace.join("\n")}")
+        Rage.logger.error("Unhandled exception has occurred - #{e.class} (#{e.message}):\n#{e.backtrace.join("\n")}")
+        Rage::Errors.report(e)
       end
     end
 
@@ -142,7 +146,7 @@ module Rage::Cable
   def self.broadcast(stream, data)
     Rage::Telemetry.tracer.span_cable_stream_broadcast(stream:) do
       __protocol.broadcast(stream, data)
-      __adapter&.publish(stream, data)
+      @__adapter&.publish(PUBSUB_BROADCASTER_ID, stream, data)
     end
 
     true
@@ -174,11 +178,6 @@ module Rage::Cable
   #     end
   #   end
 
-  module Adapters
-    autoload :Base, "rage/cable/adapters/base"
-    autoload :Redis, "rage/cable/adapters/redis"
-  end
-
   module Protocols
   end
 
@@ -191,3 +190,9 @@ require_relative "protocols/raw_web_socket_json"
 require_relative "channel"
 require_relative "connection"
 require_relative "router"
+
+if Rage.config.internal.initialized?
+  Rage::Cable.__initialize
+else
+  Rage.config.after_initialize { Rage::Cable.__initialize }
+end

data/lib/rage/cable/channel.rb

@@ -331,7 +331,8 @@ class Rage::Cable::Channel
               Fiber.schedule do
                 slice.each { |channel| callback.call(channel) }
               rescue => e
-                Rage.logger.error("Unhandled exception has occured - #{e.class} (#{e.message}):\n#{e.backtrace.join("\n")}")
+                Rage.logger.error("Unhandled exception has occurred - #{e.class} (#{e.message}):\n#{e.backtrace.join("\n")}")
+                Rage::Errors.report(e)
               end
             end
           end