Add message ordering guidance to Rails docs #288
Conversation
- Add Stimulus controller example for client-side message reordering - Document ActionCable ordering limitations - Mention async stack and AnyCable as alternatives - Include practical implementation code Related to #282
|
This seems like it would re-order the entire message object in the chat list. We don't typically see the messages as being out of order. What we see is the individual characters inside a message being out of order. Any thoughts on how to solve that w/o moving off standard ActionCable? |
docs/guides/rails.md
Outdated
|
|
||
| ### Handling Message Ordering with ActionCable | ||
|
|
||
| ActionCable doesn't guarantee message order when using certain adapters. If you experience messages appearing out of order (e.g., assistant responses appearing above user messages), you have several options: |
There was a problem hiding this comment.
I think it's not just certain adapters, it's the default behaviour?
There was a problem hiding this comment.
Yep, it's not about adapters, it's core behaviour.
See the diagram: https://speakerdeck.com/palkan/railsworld-2023-untangling-cables-and-demystifying-twisted-transistors?slide=72
(There are two thread pools involved, each one potentially causing a race condition)
docs/guides/rails.md
Outdated
|
|
||
| #### Option 2: Use the Async Stack | ||
|
|
||
| The async Ruby stack (Falcon + async-cable + async-job) may help with message ordering in single-machine deployments. See our [Async Guide]({% link guides/async.md %}) for details. Note that this approach might not guarantee ordering in all deployment scenarios, particularly in distributed systems. |
There was a problem hiding this comment.
async-cable still has the issue (so, just dropping it to the Gemfile and using Falcon won't help).
The Async solution (if I understood @ioquatix example correctly) would be to use direct writing to socket instead of broadcasting. With Action Cable, you can do that by moving the AI call from a controller to a channel (and using #transmit inside). Without Action Cable, you can achieve this by using some Async tools (like Live).
There was a problem hiding this comment.
Yes that sounds about right. The current design, IIUC, is mostly due to the limitations of existing thread-based servers and the need for an out-of-band message delivery system.
- Clarify ActionCable has NO ordering guarantees - Explain root cause: concurrent thread processing - Emphasize client-side reordering as universal solution - Add references from ioquatix and palkan feedback
crmne
force-pushed
the
docs/message-ordering-guide
branch
from
dc3b724 to
77f6135
Compare
Add notes that the message ordering controller is an example implementation that should be tested before production use
## Summary - Added documentation for handling ActionCable message ordering issues - Includes a Stimulus controller solution for client-side reordering - Mentions async stack and AnyCable as alternatives ## Context This PR addresses the message ordering issues discussed in crmne#282. The documentation includes: 1. A Stimulus controller that reorders messages based on timestamps 2. Explanation of ActionCable's ordering limitations 3. Alternative approaches (async stack, AnyCable) ## Request for Review @ioquatix @palkan - I'd appreciate your review on the technical accuracy of this documentation, particularly: - Is my description of ActionCable's ordering behavior accurate? - Are the suggested solutions appropriate? - Any other approaches you'd recommend documenting? ## Test Plan - [x] Documentation builds correctly - [x] Code examples are syntactically correct - [ ] Technical accuracy verified by domain experts
Summary
Context
This PR addresses the message ordering issues discussed in #282. The documentation includes:
Request for Review
@ioquatix @palkan - I'd appreciate your review on the technical accuracy of this documentation, particularly:
Test Plan