# Channel lifecycle This page explains what `include Hibiki::Rails::Channel` actually does under the hood, at each point in a subscription's life. You don't need any of this to use the gem — read it when you want to know where your code runs, or before overriding `subscribed` / `unsubscribed` (if you do, call `super`). The central idea: ActionCable dispatches incoming commands on a thread pool with **no per-channel ordering**, while hibiki's threading model is confinement — a graph must only ever be touched from one thread. So the concern gives every subscription a dedicated worker thread (a `GraphActor`), and cable threads only ever enqueue closures onto it. The graph is built, mutated, and disposed on exactly that one thread. **On subscribe** — the subscription is rejected without a `cid` param. Otherwise the concern starts the worker thread and posts `build_graph` to it, wrapped in `Hibiki.root`: the states, deriveds, and effects you create there are owned by that root, and the effects do their dependency-collecting first run right there, on the graph thread. **On every action** — the whole action body is posted to the graph thread and wrapped in one `Hibiki.batch`, so N signal writes in one action still mean one re-run per affected effect. `rescue_from` handlers still apply — they just run on the graph thread now; whatever they don't handle is reported to `Rails.error` with source `"hibiki_rails"` (see [Error handling layers](/hibiki/error-handling-layers/)). **On unsubscribe** — the concern disposes the root (running any `on_cleanup` hooks) and stops the worker. Already-queued actions drain first; anything posted after that is silently dropped rather than crashing a cable thread — a user navigating away can always race an in-flight click. **On code reload (development)** — an engine hook disposes every live graph before Rails reloads code, because stale effects would keep running old class versions forever. Cable clients auto-reconnect and rebuild the graph. Graph state therefore resets on reload, like any remount — expected in development, and worth remembering when a counter "mysteriously" jumps back to zero after you edit a file.

Channel lifecycle

This page explains what include Hibiki::Rails::Channel actually does under the hood, at each point in a subscription’s life. You don’t need any of this to use the gem — read it when you want to know where your code runs, or before overriding subscribed / unsubscribed (if you do, call super).

The central idea: ActionCable dispatches incoming commands on a thread pool with no per-channel ordering, while hibiki’s threading model is confinement — a graph must only ever be touched from one thread. So the concern gives every subscription a dedicated worker thread (a GraphActor), and cable threads only ever enqueue closures onto it. The graph is built, mutated, and disposed on exactly that one thread.

On subscribe — the subscription is rejected without a cid param. Otherwise the concern starts the worker thread and posts build_graph to it, wrapped in Hibiki.root: the states, deriveds, and effects you create there are owned by that root, and the effects do their dependency-collecting first run right there, on the graph thread.

On every action — the whole action body is posted to the graph thread and wrapped in one Hibiki.batch, so N signal writes in one action still mean one re-run per affected effect. rescue_from handlers still apply — they just run on the graph thread now; whatever they don’t handle is reported to Rails.error with source "hibiki_rails" (see Error handling layers).

On unsubscribe — the concern disposes the root (running any on_cleanup hooks) and stops the worker. Already-queued actions drain first; anything posted after that is silently dropped rather than crashing a cable thread — a user navigating away can always race an in-flight click.

On code reload (development) — an engine hook disposes every live graph before Rails reloads code, because stale effects would keep running old class versions forever. Cable clients auto-reconnect and rebuild the graph. Graph state therefore resets on reload, like any remount — expected in development, and worth remembering when a counter “mysteriously” jumps back to zero after you edit a file.