fix: process queued messages after session interrupt

[thoughtlesslabs]

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:

1. Aborts the current operation
2. Rejects all pending callbacks
3. Deletes session state
4. Sets status to idle

But user messages queued during the operation were already persisted to storage. After interrupt, no loop runs to process them.

Solution

1. Track loop instances with loopId - Each loop gets a unique ID to distinguish it from other loops for the same session

2. Restart loop after cancel if callbacks exist - When cancel() is called and there are pending callbacks (queued messages), automatically restart the loop to process them

3. Prevent race condition - Pass loopId to the deferred cleanup so old loop's cleanup doesn't abort the newly started loop

Changes

• Added loopId to session state tracking
• Modified start() to return both signal and loopId
• Modified cancel() to accept optional loopId and restart loop if pending callbacks exist
• Modified loop() to use loopId in deferred cleanup

[rekram1-node]

/review

[github-actions[bot]]

lgtm

[rekram1-node]

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

[thoughtlesslabs]

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 Proposed fix: https://github.com/user-attachments/assets/265f4678-4859-4d8f-8247-277c08167ce9

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.