fix: process queued messages after session interrupt#5124
fix: process queued messages after session interrupt#5124thoughtlesslabs wants to merge 3 commits into
Conversation
When interrupting a session with queued messages, the queued messages would show as 'QUEUED' but never get processed. This happened because cancel() would reject all callbacks without restarting the loop. Changes: - Add loopId to track each loop instance - Restart loop after cancel if there were pending callbacks - Use loopId to prevent old loop's cleanup from aborting new loop Fixes anomalyco#3543
Identifier.ascending() only accepts specific prefixes (message, part, permission, pty, session, user). Use ulid() which is already imported and generates unique IDs without type constraints.
|
/review |
|
lgtm |
|
Just curious so I could see the issue it solves, can u provide a video or steps to reproduce? wanna make sure i understand issue because I cant replicate it |
|
Here are two videos. The first video shows what happens with a queued command and then an interrupt on the current operation in build mode. The second video is my dev build where a queued messaged will activate after the interrupt. Current system: https://github.com/user-attachments/assets/31d50b2d-f46e-49ce-82d1-9eacd67aaab6 however, on further reflection and resting, I've realized this solution may not solve all use cases, i.e. multiple queued messages are handled in reverse sequential order after cancellation with no ability to cancel earlier queued messages. I am working on a more robust solution for handling multiple queued messages properly. I often use opencode to monitor logs on debugging which leaves a task running for quite sometime and I often queue up my followup. When I need to cancel the monito, I lose my queued message. If this is a not an issue for other users I understand just closing this out. |
00637c0 to
71e0ba2
Compare
f1ae801 to
08fa7f7
Compare
|
Closing this pull request because it has had no updates for more than 60 days. If you plan to continue working on it, feel free to reopen or open a new PR. |
2 participants
Issue
related #3543
Problem
When interrupting a session that has queued messages, the queued messages would appear as "QUEUED" in the UI but never get processed.
Root cause: When
cancel()is called, it:But user messages queued during the operation were already persisted to storage. After interrupt, no loop runs to process them.
Solution
Track loop instances with
loopId- Each loop gets a unique ID to distinguish it from other loops for the same sessionRestart loop after cancel if callbacks exist - When
cancel()is called and there are pending callbacks (queued messages), automatically restart the loop to process themPrevent race condition - Pass
loopIdto the deferred cleanup so old loop's cleanup doesn't abort the newly started loopChanges
loopIdto session state trackingstart()to return both signal and loopIdcancel()to accept optional loopId and restart loop if pending callbacks existloop()to use loopId in deferred cleanup