I don't think we need to remove it, pretty sure it was recently added, and it probably isn't finished. (it wasn't yet plugged in some UI detail?)

I don't feel strongly either way about this one, but in general I do think it's better to develop features in stages, rather than all at once. So in-between we might see something like this, not yet used. 🤷

Edited to add

If we anticipate a need to search events

Don't we anticipate the need to search events? The backend side also exists, presumably because we do?

I think we used to use it in the past, but not anymore. We don't have any design mock ups for this either at the moment, so the endpoints have just been hovering around/been relocated a couple of times

I think the reason we've kept it thus far is because 1) we forgot about it and 2) it feels weird not to have a way of getting a list of events for a conversation in our REST API -> so I think removing for now should be OK and can reintroduce when there's a planned feature that requires it?

It looks like it was introduced only last month, and the backend existed since about another month.

End of November - backend/endpoint was introduced; end of December - frontend. That looks to me like it's just being introduced gradually.

I don't think there is more history of this bit. It's recent?

Why do you think there's anything else, did you find it in the past git, or is it a guess? Ohh, or are you thinking of the filtering in get_events? That one is old, but other than some refactoring, it always did the same thing, and it's somewhat geared towards the agent use (it cares about "hidden" etc, which is agent use case). It's not the same with this search new feature, which was paginated from the start (more useful for FE use / user eyes).

I suppose there is an argument that maybe we could consolidate the filtering and this search, but... I'm not sure. I think it does make some sense to give ourselves some room for both use cases. The get_events method would get heavy if it was to support even more parameters (dates, pagination, etc). And they are different.

Idk, I guess I would leave this one alone for now. Let's see if the intentions behind it get realized and maybe it gets useful?

I've never seen this API being used and was curious about its purpose. Looking at the backend PR (#4688) description:

I needed this for debugging. e.g.:

Maybe @tofarr can clarify whether this was intended for a future feature or just a development helper.

The frontend PR (#5493) that introduced the searchEvents API call appears to have been added by OpenHands. It likely saw the backend code and assumed it needed to be implemented on the frontend. However, the actual PR (titled "Moving session initialization from WebSocket to REST API") has nothing to do with search events.

I vote to remove it but maybe @rbren or @tofarr could shed light on it's actual use. AFAIK there is no planned feature near-term that would require this and unused code can lead to misunderstandings or maintenance issues down the line

Fair enough.

Edited to add: the OpenHands theory is hilarious!