Can someone tell me what code-explorer subagent is trying to do? It invokes itself on OH Cloud when doing repo exploration and has never worked for me (fails 100% of the time) resulting in conversations getting stalled (zero progress) and eventually causing the sandbox to fail. This is kind of a big problem given repo/code exploration is a basic use case. I will provide trajectories but it's very easy to recreate. I have also created a ticket for this in the past.

Need more context. Can you link the trajectories? It is a moment that i’m not looking in subagents. But i wanted to experiment a couple of things in agent-canvas and i found a couple of regressions. So i understand that it is pretty annoying

Thanks Vasco! Will share the trajectories over DM. Before doing that, I will also have OH try to analyze the trajectories to see what happened too 😉

uff streaming is really painful... so it is a regression from what I can see... We should re-write how we handle streaming probably. Because it is creating bugs eveywhere

This would be worth prioritizing. I had another sub-agent fail (unrelated to code-explorer) this weekend. Right when the convo decided to launch the sub-agent, everything froze and the Cloud Sandbox crashed + archived the convo.

FYI: https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1787432688478709

Thanks for looking into it!

But it is a big thing... and I would like to have some feedback on that before starting to re-factoring everything. However, I really think it is worth it

Good to know. I am flagging @hundreds-twilight-32833 for visibility on this. I think the immediate symptom is it causes conversations to fail/stall (as defined in this ticket), but understanding the effort around refactoring is important so we can prioritize!

Actually there are like 6 bugs which are related to streaming… and more that are related to them undirectly :(

I don't want this to get lost so I created a "Streaming Improvements" milestone github.com/OpenHands/OpenHands/milestone/20. If you want to add any of your research to the milestone or have an agent create any issues associated with it feel free @modern-fireman-99755

And while we are at it re: streaming -- the delta events should probably not go into the trajectory trace as they are just noise there as @wooden-umbrella-84098 and @calm-artist-7206 have both previously pointed out.

I wonder if we should feature-flag streaming for the time being

IIRC codex subscription only works with streaming

right but we can just buffer everything server-side no? instead of streaming to the frontend

I think Vasco’s refactoring will make it better, we weren’t totally ready for all flow here…

Streaming was one of the big callouts from the last round of user feedback. Without it users said canvas seemed slow and it wasn't clear that it was working. The new Thinking animation may help...but not sure. But if we are going to disable it for a release or two that doesn't mean all the other folks on other releases would suddenly no longer have any of the above issues.

yeah it’s a big thing

OK if we think Vasco's work will make this better I'm game to leave it on 🙂 let's try and get it in! 🎉

Just for clarity, Vasco please correct me if wrong, the proposal implies to: • use another “envelope” object on websocket, not directly events anymore. It can be done as a “v2” for ws without affecting the other event stream, it’s just important to know; it seems it will imply changes in clients in order to upgrade and take advantage of it. It would be great if you could throw your agent at the attached file, this kind of protocol change is pretty significant IMHO. (I admit it’s not totally obvious to me that it’s necessary, but it seems a bit helpful, because the transient stuff shouldn’t be

Event

) https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1787432688478709

@calm-artist-7206 I tooke some time for the answer. But I also did a recap for everyone to make it clears what are the problems now and what we want to do. The problem today is that the agent writes a message, the broswer receives it twice: 1. The finished message saved to disk arrives when generation is done. 2. A live trickle of fragments sent while the model is still typing, so the user sees text appear. Aka the streaming. These are the same message but nothing in the system says so. So we figure this out by comparing the text (we have 600 lines of code for that). Which is not an ideal solution. Because of that we have the following issues in the UI (which are coming directly from open tickets/issues on GH): • A user typed mid-stream; the position-based guess broke • The model retried and re-streamed from the beginning; nothing announced it • The secret was split across two fragments, so masking matched neither half • ext is painted at whatever chunk size the network happened to deliver Moreover, every token is currenctly POSTed to configured webhooks (roughly one HTTP request per five tokens). So the idea is simple to solve that is: name the stream when it opens, and use the finished message's own ID as that name. (a couple of lines of code will replace ~600 lines of text-comparison guesswork 🙂 ) But the problem is that the thing that now we send over the socket is literally the same object we write to disk and it is declared strict. So we can not add an id to this object otherwise we change the disk format and we will broke old clients. So the envelope is really just for that. Just to be clear: the envelope is the event (untouched) plus delivery details. Plus point: this makes storage and streaming really independent (what we don't have now). I think this is a good solution because • the FE gets simpler (we are going to delete hundreds of lines of code) • Webhook token spam disappears • Resume-after-disconnect comes free.