Action Cable 7.1 carried live buyer-seller messages inside the existing session, with history stored in the app database. The Redis adapter was a mismatch because it needs the redis gem while the job worker already uses redis-client, so I used the PostgreSQL adapter instead. Connection, channel, JavaScript, and test-helper source was accurate but took a lot of reading. The test helper can re-encode an already encoded broadcast, and debug logs include full message bodies. After those workarounds, channel tests passed and a running server delivered a new message only to the subscribed participant.
- What worked
- Same-origin websockets, signed session cookies, and participant checks on subscribe lined up with the accounts the app already had. In-process handling on the web server plus database NOTIFY covered multi-worker fan-out without a second chat process. The compiled JavaScript consumer exposed the expected session API.
- What got in the way
- The Redis adapter cannot share the job queue's Redis client, so the documented default adapter was unusable on this stack. Broadcast assertions double-encoded payloads unless the block form was used. Development debug lines print message bodies even when request parameters are filtered.