Guidance request: Rails 8 + Falcon + Async Cable/Job, while keeping Solid stack (solid queue, solid cache, solid cable) working

[darkamenosa]

Hi Samuel,

First of all, I want to thank you for Falcon and the async ecosystem.

I've been moving my app in that direction and would love your guidance on a simple, safe path.

Where I am

• I switched from Puma to Falcon a while ago. It's been good.

• After reading your keynote, I made my my config explicit follow the slide and added:

  # application.rb
  config.active_record.permanent_connection_checkout = :disallowed
  config.active_support.isolation_level = :fiber

• After I put those in, my jobs process (Solid Queue) started looping with an AR (ActiveRecord) connection error when the scheduler tries to persist recurring tasks. I'm not filing a bug here, just asking for the best way to transition.

Key context lines I see:

ActiveRecord::ConnectionHandling#connection: Called deprecated `ActiveRecord::Base.connection` method. (ActiveRecord::ActiveRecordError)
Either use `with_connection` or `lease_connection`.

from solid_queue-1.2.1/app/models/solid_queue/recurring_task.rb:39
from solid_queue-1.2.1/lib/solid_queue/scheduler/recurring_schedule.rb:45
...

My understanding: with :disallowed, code should use ActiveRecord.with_connection { ... } or lease_connection (no permanent checkout). That likely explains the loop.

I tried to do monkey patch for this, and new problems happen with Solid cache, just same issue.

And I checked their codebase, it seems only design for thread base isolation now.

My goal

• Move to Falcon + Async Cable + Async Job.
• But keep Solid Queue / Solid Cache / Solid Cable working during the transition because the their UI (misson control) observability helps me a lot in production.
• Minimal changes, keep what I already have, and gradually shift things that benefit from async/fibers.

How my jobs are set up (why I mix today)

My app runs bin/dev which starts web (Falcon), jobs (Solid Queue supervisor), and vite.

• IO‑heavy, short tasks (e.g., AI responses): I use async‑job with an Inline processor on a dedicated queue. It's simple and responsive, no extra moving parts for these quick jobs.

  # Define a queue named "local" which uses the Inline backend:
  config.async_job.define_queue "local" do
    dequeue Async::Job::Processor::Inline
  end

• Production‑critical flows that need a UI (e.g., publishing posts to Facebook/TikTok): I keep these on Solid Queue. I tried bundle exec async-job-adapter-active_job-server, but without a UI like Solid Queue it was hard to trace failures and see state at a glance, so the UI matters. I also use Solid Queue for jobs which are more CPU‑heavy and operationally sensitive.

So I'm in the mix: async‑job Inline for fast IO stuff; Solid Queue for the important, observable workflows.

I'd like to keep this for now, if it plays well with Falcon/fibers. But I'm not sure about this after seeing the error.

Cable plans

• I plan to switch to Async Cable too, my app use websocket a lot, so thread base might not ideal. I'm not sure how that should interact with (or replace) Solid Cable under Falcon/fibers.

What I need guidance on

1. Rails 8 on Falcon: should I just turned off permanent_connection_checkout = :disallowed just to make the solid stack works, will there any problems?

2. If I move more jobs to async-job-adapter-active_job-server, what's your recommended path to production observability (logs/metrics/instrumentation) comparable to Solid Queue's UI? I'm thinking building a UI for async-job-adapter-active_job-server if no.

3. Cable: best practice for Async Cable with Rails 8 + Falcon. Should it replace Solid Cable, or can they coexist? Any gotchas when migrating from Action Cable to Async Cable in a fiber‑first app?

Sorry about asking these dumb question b/c of lacking experience here.

Environment (for reference)

• Ruby 3.4.4
• Rails 8.0.2.1
• Falcon 0.52.3
• Solid Queue 1.2.1 (Solid Cache in use; Solid Cable planned)
• macOS (development)

I'm Hhppy to share a small repro and test whatever you suggest. Thanks again, I'm trying to do this with minimal churn and keep the good parts I have today while moving toward Falcon + Async.

[darkamenosa]

I just tested to put Async Cable to the site, to use with solid cable. And here is what I got:

 {"time":"2025-10-02T15:55:45+07:00","severity":"warn","pid":41495,"oid":20808,"fiber_id":20792,"subject":"Async::Task","annotation":"Reading HTTP/1.1 requests for Async::HTTP::Protocol::HTTP1::Server.","message":"Task may have ended with unhandled exception.","event":{"type":"failure","root":"/Users/tuyenhx/Workspace/turnedninja/rails_social_scheduler","class":"NoMethodError","message":"\u001b[1mundefined method 'mutex' for nil (\u001b[1;4mNoMethodError\u001b[m\u001b[1m)\u001b[m\n\n\u001b[1m          @listener || @server.mutex.synchronize do\u001b[m\n\u001b[1m                              ^^^^^^\u001b[m","backtrace":["/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/solid_cable-3.0.12/lib/action_cable/subscription_adapter/solid_cable.rb:36:in 'ActionCable::SubscriptionAdapter::SolidCable#listener'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/solid_cable-3.0.12/lib/action_cable/subscription_adapter/solid_cable.rb:29:in 'ActionCable::SubscriptionAdapter::SolidCable#unsubscribe'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/actioncable-next-0.2.0/lib/action_cable/subscription_adapter/channel_prefix.rb:20:in 'ActionCable::SubscriptionAdapter::ChannelPrefix#unsubscribe'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/actioncable-next-0.2.0/lib/action_cable/connection/internal_channel.rb:32:in 'block in ActionCable::Connection::InternalChannel#unsubscribe_from_internal_channel'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/actioncable-next-0.2.0/lib/action_cable/connection/internal_channel.rb:32:in 'Array#each'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/actioncable-next-0.2.0/lib/action_cable/connection/internal_channel.rb:32:in 'ActionCable::Connection::InternalChannel#unsubscribe_from_internal_channel'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/actioncable-next-0.2.0/lib/action_cable/connection/base.rb:101:in 'ActionCable::Connection::Base#handle_close'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-cable-0.3.0/lib/async/cable/middleware.rb:61:in 'Async::Cable::Middleware#handle_incoming_websocket'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-cable-0.3.0/lib/async/cable/middleware.rb:31:in 'block in Async::Cable::Middleware#call'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-websocket-0.30.0/lib/async/websocket/adapters/http.rb:41:in 'block in Async::WebSocket::Adapters::HTTP.open'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-http-0.91.0/lib/async/http/body/hijack.rb:39:in 'Async::HTTP::Body::Hijack#call'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/rack-3.2.1/lib/rack/body_proxy.rb:56:in 'Method#call'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/rack-3.2.1/lib/rack/body_proxy.rb:56:in 'Rack::BodyProxy#method_missing'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/rack-3.2.1/lib/rack/body_proxy.rb:56:in 'Rack::BodyProxy#method_missing'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/rack-3.2.1/lib/rack/body_proxy.rb:56:in 'Rack::BodyProxy#method_missing'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/rack-3.2.1/lib/rack/body_proxy.rb:56:in 'Rack::BodyProxy#method_missing'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/protocol-http-0.53.0/lib/protocol/http/body/streamable.rb:129:in 'Protocol::HTTP::Body::Streamable::Body#call'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-http-0.91.0/lib/async/http/protocol/http1/server.rb:97:in 'block in Async::HTTP::Protocol::HTTP1::Server#each'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-2.31.0/lib/async/task.rb:348:in 'Async::Task#defer_stop'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-http-0.91.0/lib/async/http/protocol/http1/server.rb:81:in 'Async::HTTP::Protocol::HTTP1::Server#each'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-http-0.91.0/lib/async/http/server.rb:49:in 'Async::HTTP::Server#accept'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/falcon-0.52.3/lib/falcon/server.rb:57:in 'Falcon::Server#accept'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/io-endpoint-0.15.2/lib/io/endpoint/wrapper.rb:216:in 'block (2 levels) in IO::Endpoint::Wrapper#accept'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-2.31.0/lib/async/task.rb:207:in 'block in Async::Task#run'","/Users/tuyenhx/.asdf/installs/ruby/3.4.4/lib/ruby/gems/3.4.0/gems/async-2.31.0/lib/async/task.rb:452:in 'block in Async::Task#schedule'"]}}

So I did a custom implementation of turbo rails, but tailor for my application (inertia rails). When broadcast, I call an async job (with inline adapter) to broadcast.

[ioquatix]

Okay, with regards to SolidQueue, I think they basically need to fix their code to be safe when :disallowed is set. I filed an issue for this: rails/solid_queue#646

In the mean time, it's probably okay to run without config.active_record.permanent_connection_checkout = :disallowed although it's good practice to probably check your own code for issues (excepting SolidQueue).

For context, there has been some discussion around SolidQueue supporting Async / Fiber scheduler but it's not something I can say when it will happen (or not). Depending on the performance of the database, this may or may not make sense.

Regarding MissionControl, maybe that's something we can try to build for Falcon / Async::Job. That being said, it might just be better to use an APM (or build a very basic one).

I plan to switch to Async Cable too, my app use websocket a lot, so thread base might not ideal. I'm not sure how that should interact with (or replace) Solid Cable under Falcon/fibers.

In principle if they are following Rails conventions, it should work. That means they should be using IsolatedExecutionState etc. If it doesn't work I'd encourage you to file a bug report.

Rails 8 on Falcon: should I just turned off permanent_connection_checkout = :disallowed just to make the solid stack works, will there any problems?

The point of that option is to detect use cases that checkout a database connection permanently. If your own code doesn't have this problem, then the value of this configuration won't change anything. So, in principle, it's safe to ignore this option for now.

If I move more jobs to async-job-adapter-active_job-server, what's your recommended path to production observability (logs/metrics/instrumentation) comparable to Solid Queue's UI? I'm thinking building a UI for async-job-adapter-active_job-server if no.

A proper APM + https://github.com/socketry/traces + https://github.com/socketry/metrics - we can add more command line tools for job manipulation if that's helpful.

Cable: best practice for Async Cable with Rails 8 + Falcon. Should it replace Solid Cable, or can they coexist? Any gotchas when migrating from Action Cable to Async Cable in a fiber‑first app?

I think you should probably just replace it. Async::Cable completely replaces the guts of ActionCable because it lacks modularity. I don't even know how SolidCable works without monkey patching Rails.

Hope this helps, let me know if you have more questions or need more specifics.

[darkamenosa]

I just finished read the repo. I have a question:

• It seems on web socket demo, you just ignore completely their ActionCable, and use Async Websocket. How do we handle security check here? Like only authenticated users allowed.

About lively, it looks good. I need to dig more on the source code. However, I'm not a big fan of building html in ruby code. So I might tweak it for json to send to frontend to render with kind of react code.

So excited to build something fun with this kind of stuffs.

[darkamenosa]

Oh, there is an important features I forgot to ask. But checking the code it seems, we haven't implemented it, that read config/recurring.yml.

Do you think bundle exec async-job-adapter-active_job-server should support this?

[ioquatix]

Yes, I didn't know about that. We already have https://github.com/socketry/async-cron so it might just be a matter of bridging that gap.

[darkamenosa]

Not sure this would help, but I think you should think carefully on the naming. bundle exec async-job-adapter-active_job-server just too long and hard to remember, even when look for in the code. The whole ecosystem is great, but naming :( ...

falcon is a good name. Maybe you can start thinking on that angle. I'm reading the async cron now.

[ioquatix]

The problem with creating bespoke names for technology is it becomes really hard to make sense of anything. I agree the async-job names are verbose but they are consistent which is more important IMHO.