Untangling cables and demystifying twisted transistors
summary
Action Cable exposes a simple channel API but under the hood it uses an action-cable protocol with a client consumer/subscription model, a monitor that pings every 3s (no pongs) and a server-side 4-thread executor (concurrent-ruby) with an unbounded queue, which causes concurrent processing of commands, race conditions on subscribe/unsubscribe, and nondeterministic broadcast ordering. There are no message IDs or acknowledgements so delivery is at-most-once, missed messages aren’t recoverable, and server restarts can trigger a connection avalanche. Mitigations: randomized reconnects (Rails 7), subscription serialization, size DB pool = web threads + cable threads, or use AnyCable.
AI-written summary · about
chapters (9)
- 0:00Introduction to rails
- 2:37Action cable interface
- 5:57Client-side architecture
- 9:21Protocol and custom clients
- 12:32Handling server failures
- 17:28Server-side internals
- 22:00Broadcasting mechanisms
- 26:27Turbo streams integration
- 29:46Connection avalanche problem
