Search Bar Enhancement: add message content search backend

[Kaveh-Vakili]

Goes with SEMOSS/semoss-ui#3445

Description

Formulated a more robust solution for the playground search bar that is able to search for content within different rooms.

Changes Made

• SearchRoomMessagesReactor: add limit, offset, includeMessageText keys; remove projectId fallback so omitting it searches across all projects; wire 6-arg searchMessages; update reactor description
• ModelInferenceLogsUtils: add 6-arg searchMessages overload with pagination and optional message text; backward-compat 3-arg delegate; add room_name/date_created selectors; LOWER() wrap for case-insensitive LIKE; % wildcards on keyword; null-guard on projectId

How to Test

1. Create multiple different rooms with conversations
2. With the Playground search bar, search for content within those rooms

Notes

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[tlokeshrao]

Overall: Validated the reactor live against a running instance — content search, all-projects default, room_name/date_created, optional message text, case-insensitivity, and pagination all work. A few things in the new code to address before merge.

Should fix

1. limit/offset parsing is outside the try/catch.
   The new Long.parseLong calls run before the try block, so a non-numeric value throws an uncaught NumberFormatException. Reproduced live: SearchRoomMessages(search=["the"], limit=["abc"]) returns ERROR: For input string: "abc" instead of the reactor's own error handling. Move the parse inside the try, or validate first.

2. Redundant LOWER/%/toLowerCase in the new filter.
   ?like (the comparator already in use) lowercases both sides and wraps the value in %…% itself. The new lowerMessageSelector + "%" + keyword.toLowerCase() + "%" therefore generates LOWER(LOWER(…)) LIKE '%%keyword%%'. It's functionally fine (idempotent, %%≡%), but it obscures intent — and the commit frames it as a case-insensitivity fix that ?like was already providing (the old path was already case-insensitive). Filtering on messageTextSelector directly with the raw keyword gets the same result with less code.

Minor
3. Add a unique tiebreaker to the ORDER BY now that pagination exists.
Ordering is ROOM__DATE_CREATED DESC, MESSAGE__DATE_CREATED DESC. That was harmless before, but the limit/offset you added mean a timestamp tie can now skip or duplicate a row across pages. Appending MESSAGE__MESSAGE_ID makes paging deterministic.

4. Doc drift in the changed code. The rewritten getReactorDescription lists room_id/message_id (+ optional message_text) but not the room_name/date_created you added. The 3-arg searchMessages Javadoc (@return (room_id, message_text, message_id)) is also stale after the new columns.

[tevanburen]

I'm seeing some funky behavior with this reactor, it's returning "rooms" that shouldn't be exposed to the user, like summarization and prompt optimization "rooms" for example

[tevanburen]

Also, it appears not to be returning valid rooms when it ought to, like when I'm actually searching for a real message it doesn't come back

[Kaveh-Vakili]

We'd have to revert ROOM_ID != INSIGHT_ID filter since Thomas confirmed it's also filtering out valid rooms. To properly fix this we'd need a schema change. Either an IS_SYSTEM flag on internal rooms or an IS_USER_CREATED flag on user rooms.

[kunal0137]

Confirmed locally: pagination is applied to matching messages, but the UI displays matching rooms.
For example, assume Room A contains 50 separate messages containing “spain,” while Room B contains one message containing “spain.” With limit=50, the backend can return all 50 rows from Room A. The UI then deduplicates those rows and displays only Room A, so Room B is incorrectly missing.
In my local data, “spain” matched 136 messages across 44 rooms. The first 50 message rows represented only 18 rooms, leaving 26 valid matching rooms out of the results.
The backend should reduce the results to one row per room before applying limit and offset. When testing, ensure the room name does not contain the search term; otherwise the separate room-name search masks this issue.

additionally infinite or additonal scroll doesnt work after.

[tevanburen]

we should have SearchRoomMessages return room date_created instead of message date_created (right now it's pulling MESSAGE__DATE_CREATED while GetPlaygroundRooms pulls ROOM__DATE_CREATED under the same field name, so the same room can show two different dates depending on which endpoint returns it)