I was looking into issues with our status indicator in the UI and I'd like to propose a small change. Instead of attempting to determine the right state to show by comparing multiple status' (agent status state, server status state), I was thinking of just presenting each individual status as it's own indicator. We have FOUR different status' to consider: 1. WS connection status 2. Agent status 3. Conversation status 4. Runtime status I originally was just experimenting with this UI to help me debug, but I feel like it will also be a good indicator of what is going on for the user as well. cc @elegant-branch-54423 @wooden-umbrella-84098 @breezy-kilobyte-39430 The only regression here is that we use to be able to "Stop Conversation" by clicking on the server status indicator. We can either move it somewhere else but the user can already stop conversation via conversation panel or the context menu from the conversation title in the conversation screen. Thoughts?

I do like the idea of showing progress (25%, 50%, 75%, 100% - Ready) instead of arbitrary statuses. I would like @breezy-kilobyte-39430 to weigh in on how best to display this 'progress-bar' approach. I even think 4 dots (instead of icons) could be sufficient.

I added this part of PR to fix incorrect status' being displayed. Currently we check some of these values (e.g., runtime status vs agent status vs conversation status) and have a priority of which status to show. This be challenging though as there are some edge cases where the prioritised status is not the best one and may result in stale-looking indicators (e.g., stuck on starting when its ready, or some cases stuck on initializing agent) I'll update the PR to include the original fix without the UI changes shown in the screenshot, but it may continue to be harder for us to understand when or why conversations don't behave as they are supposed to. So maybe we can address this soon to make our and user experience a little less confusing

This is nice! Wow, four of them is… a lot though lolsob

We'll get rid of the runtime status' since we're decoupling from the sandbox in V1, right?

What… does Stop Conversation mean? Is it the runtime pause or is it the agent stop thinky spin

It is the runtime pause

OK, that is one extra click away, but IMHO good enough

This is non-blocking feedback: Just looked at teh feature branch, and I think there is promise with these icons. Some confusing things: 1. When I first load the convo, I expect to read the statuses from left to right. However, the 3rd icon is gray and the rest are yellow, which just seems out of order. 2. I'd expect the first icon to maybe be yellow, and the rest gray (indicating some sort of 'progress') 3. To help further explain what's going on, I think having the status text is helpful. I know I can hover over the icons to get status, but each one says something different so it's unclear what the current status is. 4. Overall, I think there is a ton of promise here and I like where this is headed - but my simple-brain assumes this is akin to a battery charging indicator (e.g., 20% full --> 100% full and ready to use)

When I first load the convo, I expect to read the statuses from left to right. However, the 3rd icon is gray and the rest are yellow, which just seems out of order.

This is tricky to setup because each status does not necessarily depend on another. For example, agent could error but the conversation is still active. Or runtime could fail but we are still connected via WS. This is also why it could be difficult to make it an incrementing status like 20% -> 100% since at any time for any reason, one of the indicators could fail for some reason. Would that mean we go back to an 80%? Just sharing some more context on why I've made 4 separate indicators. Anyways, I'll revert the UI changes for now but would like to keep this on our radar

Hey all, let me work on this and come up with some variants.

IMO "Conversation status" should not be a thing here. It seems like we're duplicating some runtime statuses with starting/running/stopped. Conversation status should just be active/archived, and only active convos should be able to access this screen

Are we expecting this to only be visible when the convo is first starting or persistent?

Preferably persistent since they give the user updates on what might be happening on the background. We can receive different status' throughout a conversation lifecycle, usually when something goes wrong

I think there are enough moving parts here with v1 that we should table the discussion until we know more about how the runtimes will work. Hopefully things get simpler 🤞