Torque Admin usesDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/crashtech/torque-admin/llms.txt
Use this file to discover all available pages before exploring further.
ActionController::Live to stream HTTP responses for pages that are computationally expensive to render — such as index listings with many associations or dashboards with aggregated statistics. Rather than holding the full response in memory and flushing it all at once, the engine writes output to the client progressively, allowing the browser to begin rendering before the server has finished processing.
How StreamController Works
Torque::Admin::StreamController is an ActiveSupport::Concern that powers the streaming behaviour. It is included automatically by both ResourceController and DashboardController, so you do not need to add it yourself to standard resource controllers.
When the concern is included in a controller, it performs a careful alias dance at include time:
process_properly method inspects async_action? and delegates to either process_async (streaming) or process_sync (standard Rails), keeping the streaming entirely transparent to the rest of the controller stack.
Thread-local key
The concern uses the thread-local keyStreamController::Key — defined as the symbol :'torque@async' — to track every async process spawned on the current thread. This key is initialised to an empty array before the action runs and set back to nil in an ensure block after all futures are collected.
Opting Actions into Streaming
The class methodstream_from_actions registers action names that should use the streaming pipeline:
ResourceController calls this automatically when the application-level stream_actions: true config is set:
DashboardController does the same for its :index action by calling stream_actions :index directly in its included block when admin_application.config.stream_actions is truthy.
The protected instance method async_action? answers whether the current dispatch should stream:
Parallel Processing Inside an Action
Within a streaming action you can fork work into background tasks usinginitialize_async_process. The block you pass is executed in parallel; the response stream stays open while all tasks run.
parallel_processing_with: in your application config:
| Config value | Backend |
|---|---|
:concurrent_ruby (default) | Concurrent::Future.execute |
:async | The Async gem’s Async {} block |
false | Disabled — the block runs inline (no parallelism) |
concurrent_ruby future runs the block inside ActiveSupport::IsolatedExecutionState.share_with(t1, &block), where t1 is the parent thread — preserving request-local state such as Current attributes across the thread boundary.
Waiting for all processes
At the end of every streaming action,wait_all_async_processes! is called automatically from process_action’s ensure block. It iterates over every registered future:
- For
:concurrent_ruby— calls.wait!(raises on error) or.cancelif a prior future errored. - For
:async— calls.waitor.cancelsimilarly.
Thread safety is maintained because each
concurrent_ruby async process receives its own isolated execution state, shared from the parent thread via ActiveSupport::IsolatedExecutionState.share_with. This means ActiveSupport CurrentAttributes, database connections, and other thread-local state are properly propagated without races.Configuration
Disable streaming globally
Setstream_actions: false in your application config to prevent ResourceController and DashboardController from ever registering streaming actions:
Choose a parallel backend
Opt a specific controller out
Overrideasync_action? to return false, or reset stream_actions to an empty frozen array:
Add streaming to a custom action
Usestream_from_actions in the controller class body:
