lhumina_code/hero_agent
25
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

New-conversation "+" button: conv is created but never appears in sidebar or opens #6

New issue
Closed
opened 2026-04-23 10:35:27 +00:00 by rawan · 6 comments
rawan commented 2026-04-23 10:35:27 +00:00
Member
Copy link

Summary

Clicking the + button in the Chat sidebar does send a POST /api/conversations request and the conversation is created on the server, but:

  1. The new conversation never appears in the sidebar list.
  2. No new chat window opens — the chat area stays in the welcome state, the conversation label is not updated.

Repro

  1. Open the Hero Agent UI → Chat tab.
  2. Click the + button next to Conversations.
  3. Observe network tab: POST /api/conversations → 200 with {id, title, ...}.
  4. Observe sidebar: still shows No conversations yet.
  5. Observe chat area: still shows the welcome state, label unchanged.

Verified live against the running server:

$ curl --unix-socket ~/hero/var/sockets/hero_agent/ui.sock http://localhost/api/conversations
{"conversations":[]}

Root cause

Bug 1 — list endpoint shape mismatch

GET /api/conversations returns an object, but the frontend expects a bare array.

Server (crates/hero_agent_server/src/routes.rs:808-810):

Json(serde_json::json!({
    "conversations": conversations
}))

Frontend (crates/hero_agent_ui/static/js/dashboard.js:106-111):

var convs = await api('conversations');
if (!Array.isArray(convs) || convs.length === 0) {
  list.innerHTML = '<div class="text-secondary small p-3">No conversations yet</div>';
  return;
}

Array.isArray({conversations: []}) is false, so the sidebar always renders "No conversations yet" regardless of how many conversations exist on the server. This is why the newly-created conversation never appears after createConversation calls loadConversations().

Note: the sibling endpoint GET /api/conversations/{id}/messages returns a bare array (crates/hero_agent_server/src/routes.rs:877), so loadConversationMessages works correctly. The list endpoint is the inconsistent one.

Bug 2 — createConversation doesn't visibly switch context

createConversation (crates/hero_agent_ui/static/js/dashboard.js:136-152) sets currentConversationId and calls loadConversationMessages(data.id), but:

  • It does not update #chat-conversation-label (only selectConversation does that, line 131).
  • For a brand-new conversation, loadConversationMessages just renders the same welcome state that was already there.

Net effect: nothing in the chat area visibly changes when the new conv is created, so it looks like the click did nothing.

Suggested fixes

Bug 1 — pick one:

  • Server: change list_conversations to Json(serde_json::json!(conversations)) (bare array — matches get_conversation_messages style).
  • Or frontend: var convs = (await api('conversations')).conversations || [].

Server-side fix is preferred for consistency with the rest of the API.

Bug 2: in createConversation, after the POST succeeds, just delegate to selectConversation(data.id) so the label, sidebar highlight, and message pane all update through one path.

Affected files

  • crates/hero_agent_server/src/routes.rs (list_conversations)
  • crates/hero_agent_ui/static/js/dashboard.js (loadConversations, createConversation)
## Summary Clicking the `+` button in the Chat sidebar does send a `POST /api/conversations` request and the conversation **is** created on the server, but: 1. The new conversation never appears in the sidebar list. 2. No new chat window opens — the chat area stays in the welcome state, the conversation label is not updated. ## Repro 1. Open the Hero Agent UI → `Chat` tab. 2. Click the `+` button next to `Conversations`. 3. Observe network tab: `POST /api/conversations` → 200 with `{id, title, ...}`. 4. Observe sidebar: still shows `No conversations yet`. 5. Observe chat area: still shows the welcome state, label unchanged. Verified live against the running server: ``` $ curl --unix-socket ~/hero/var/sockets/hero_agent/ui.sock http://localhost/api/conversations {"conversations":[]} ``` ## Root cause ### Bug 1 — list endpoint shape mismatch `GET /api/conversations` returns an **object**, but the frontend expects a bare **array**. Server (`crates/hero_agent_server/src/routes.rs:808-810`): ```rust Json(serde_json::json!({ "conversations": conversations })) ``` Frontend (`crates/hero_agent_ui/static/js/dashboard.js:106-111`): ```js var convs = await api('conversations'); if (!Array.isArray(convs) || convs.length === 0) { list.innerHTML = '<div class="text-secondary small p-3">No conversations yet</div>'; return; } ``` `Array.isArray({conversations: []})` is `false`, so the sidebar **always** renders "No conversations yet" regardless of how many conversations exist on the server. This is why the newly-created conversation never appears after `createConversation` calls `loadConversations()`. Note: the sibling endpoint `GET /api/conversations/{id}/messages` returns a bare array (`crates/hero_agent_server/src/routes.rs:877`), so `loadConversationMessages` works correctly. The list endpoint is the inconsistent one. ### Bug 2 — createConversation doesn't visibly switch context `createConversation` (`crates/hero_agent_ui/static/js/dashboard.js:136-152`) sets `currentConversationId` and calls `loadConversationMessages(data.id)`, but: - It does **not** update `#chat-conversation-label` (only `selectConversation` does that, line 131). - For a brand-new conversation, `loadConversationMessages` just renders the same welcome state that was already there. Net effect: nothing in the chat area visibly changes when the new conv is created, so it looks like the click did nothing. ## Suggested fixes **Bug 1 — pick one:** - Server: change `list_conversations` to `Json(serde_json::json!(conversations))` (bare array — matches `get_conversation_messages` style). - Or frontend: `var convs = (await api('conversations')).conversations || []`. Server-side fix is preferred for consistency with the rest of the API. **Bug 2:** in `createConversation`, after the POST succeeds, just delegate to `selectConversation(data.id)` so the label, sidebar highlight, and message pane all update through one path. ## Affected files - `crates/hero_agent_server/src/routes.rs` (`list_conversations`) - `crates/hero_agent_ui/static/js/dashboard.js` (`loadConversations`, `createConversation`)
rawan self-assigned this 2026-04-26 07:01:26 +00:00
rawan commented 2026-04-26 10:24:38 +00:00
Author
Member
Copy link

Implementation Spec: Issue #6

New-conversation + button: conv is created but never appears in sidebar or opens

Objective

Fix two regressions in the Chat sidebar so that:

  1. The conversation list returned by GET /api/conversations is rendered in the sidebar (not always shown as "No conversations yet").
  2. Clicking the + button creates a new conversation AND visibly switches the chat UI to that new conversation (sidebar highlight, label, and message pane all update through one path).

Requirements

  • GET /api/conversations MUST return a JSON array of conversation summaries (consistent with GET /api/conversations/:id/messages, which already returns a bare array).
  • The OpenRPC spec (openrpc.json) for agent.conversations.list and the matching schema MUST be updated to advertise the array shape.
  • The generated OpenRPC client (openrpc.client.generated.rs) MUST be regenerated to match the new schema.
  • All existing scripts and docs that depend on the { "conversations": [...] } shape MUST be updated to expect the bare-array shape.
  • After a successful POST /api/conversations, the frontend MUST call selectConversation(newId) so the sidebar highlight, the #chat-conversation-label, and the message pane all reflect the new conversation through a single code path.
  • The existing welcome-state behavior on an empty new conversation MUST be preserved (label switches; chat area shows the welcome stub via loadConversationMessages's empty-array branch).

Files to Modify

1. crates/hero_agent_server/src/routes.rs

  • list_conversations (lines 857-878): change to return a bare array instead of {"conversations": ...}.
  • The inline OpenRPC spec at lines 118-123 already advertises "type": "array", so it stays consistent (verify after edit).

2. crates/hero_agent_server/openrpc.json

  • agent.conversations.list method (lines 266-276): change result.schema.$ref from ConversationListResponse to an inline array of ConversationSummary.
  • ConversationListResponse schema (lines 825-836): remove the now-orphan schema.

3. crates/hero_agent_server/openrpc.client.generated.rs

  • Auto-generated from openrpc.json. Regenerate after step 2. Expected diff: ConversationListResponse struct disappears; AgentConversationsListOutput becomes a bare Vec<ConversationSummary>.

4. crates/hero_agent_ui/static/js/dashboard.js

  • loadConversations (lines 104-127): already correctly checks Array.isArray(convs). After server fix, works without modification.
  • createConversation (lines 136-152): after data.id is received, replace the manual currentConversationId = data.id; loadConversations(); loadConversationMessages(data.id); block with selectConversation(data.id) so label, sidebar highlight, and message pane all update through one path.

5. scripts/smoke-test.sh

  • Lines 189-194: assertion if echo "$resp" | grep -q "conversations" will no longer match a bare array. Update to assert the response starts with [, matching the existing /api/jobs assertion pattern.

6. tests/browser/chat_ui_test.md

  • Line 53: tighten "Array/object with conversations" to "Array of conversation summaries".

Step-by-Step Implementation Plan

Step 1 — Change list_conversations to return a bare array

  • File: crates/hero_agent_server/src/routes.rs
  • Replace the final Json(serde_json::json!({ "conversations": conversations })) with Json(serde_json::json!(conversations)).
  • Dependencies: none.

Step 2 — Update openrpc.json schema for agent.conversations.list

  • File: crates/hero_agent_server/openrpc.json
  • In the method entry, change result schema to {"type":"array","items":{"$ref":"#/components/schemas/ConversationSummary"}}.
  • Remove the now-unused ConversationListResponse component schema.
  • Dependencies: none (independent of step 1, but they ship together).

Step 3 — Regenerate the OpenRPC client inspection file

  • File: crates/hero_agent_server/openrpc.client.generated.rs
  • Trigger a build of hero_agent_server to refresh the inspection copy via the openrpc_client! macro.
  • Dependencies: step 2.

Step 4 — Wire createConversation through selectConversation

  • File: crates/hero_agent_ui/static/js/dashboard.js
  • In createConversation, after if (data.id) {, replace the body with a single call: selectConversation(data.id);
  • Dependencies: none. Independent of server-side fix.

Step 5 — Update smoke-test assertion

  • File: scripts/smoke-test.sh
  • Lines 189-194: change grep -q "conversations" to assert array shape ([), update messages to mention "array".
  • Dependencies: step 1.

Step 6 — Tighten chat UI test documentation

  • File: tests/browser/chat_ui_test.md
  • Line 53: "Array/object with conversations" -> "Array of conversation summaries".
  • Dependencies: step 1.

Step 7 — Build, run smoke tests, and manual repro

  • Build the workspace.
  • Run scripts/smoke-test.sh to verify the new assertion holds.
  • Manual repro: open the Chat tab, create a conversation via +, confirm sidebar lists/highlights it, label updates, chat area shows welcome state.

Acceptance Criteria

  • GET /api/conversations returns a JSON array (bare [...]), not an object.
  • The inline OpenRPC spec at routes.rs:118-123 and the static openrpc.json agree: result is array.
  • openrpc.json no longer references ConversationListResponse; the orphan schema is removed.
  • openrpc.client.generated.rs is regenerated and reflects the new array shape.
  • In the UI, clicking + in the Chat sidebar creates a conversation AND immediately:
    • adds it to the sidebar list,
    • highlights it as the active conversation,
    • sets #chat-conversation-label to the new conversation ID,
    • swaps the chat area to the welcome state for an empty conversation.
  • loadConversations correctly renders existing conversations on dashboard load.
  • scripts/smoke-test.sh passes with the updated assertion.
  • scripts/browser-mcp-test.sh test 4.5 and test 6.2 still pass.
  • Manual repro from the issue body confirms all observed bugs are fixed.

Notes

Risks / consumers

  • OpenRPC generated client: ConversationListResponse and AgentConversationsListOutput will change shape. A repo-wide grep shows NO consumers outside the generated file itself — inspection-only. Safe.
  • agent.conversations.list JSON-RPC method: the inline OpenRPC spec at routes.rs:119-123 already advertises "type": "array" (already inconsistent with the REST handler today). The dispatcher does NOT actually implement this method — calls fall through to "Method not found". No live RPC consumer depends on the wire shape today. Safe.
  • Smoke test: must be updated in the same commit (line 190 greps for the literal "conversations" substring).
  • Browser MCP test: already accepts both conversations|\[, so it keeps passing. Optional cleanup only.

Why server-side fix is correct

  • Consistent with GET /api/conversations/:id/messages, which already returns a bare array.
  • Frontend code and OpenRPC inline spec already EXPECT an array. Aligning the REST handler removes the inconsistency in two places at once.
  • No external consumers beyond the auto-generated client.

Edge case

  • selectConversation(id) uses id as the label text. For a brand-new conv, the label shows the UUID. Friendlier labels (e.g. data.title) are an unrelated UX improvement and out of scope.
# Implementation Spec: Issue #6 New-conversation `+` button: conv is created but never appears in sidebar or opens ## Objective Fix two regressions in the Chat sidebar so that: 1. The conversation list returned by `GET /api/conversations` is rendered in the sidebar (not always shown as "No conversations yet"). 2. Clicking the `+` button creates a new conversation AND visibly switches the chat UI to that new conversation (sidebar highlight, label, and message pane all update through one path). ## Requirements - `GET /api/conversations` MUST return a JSON array of conversation summaries (consistent with `GET /api/conversations/:id/messages`, which already returns a bare array). - The OpenRPC spec (`openrpc.json`) for `agent.conversations.list` and the matching schema MUST be updated to advertise the array shape. - The generated OpenRPC client (`openrpc.client.generated.rs`) MUST be regenerated to match the new schema. - All existing scripts and docs that depend on the `{ "conversations": [...] }` shape MUST be updated to expect the bare-array shape. - After a successful `POST /api/conversations`, the frontend MUST call `selectConversation(newId)` so the sidebar highlight, the `#chat-conversation-label`, and the message pane all reflect the new conversation through a single code path. - The existing welcome-state behavior on an empty new conversation MUST be preserved (label switches; chat area shows the welcome stub via `loadConversationMessages`'s empty-array branch). ## Files to Modify ### 1. `crates/hero_agent_server/src/routes.rs` - `list_conversations` (lines 857-878): change to return a bare array instead of `{"conversations": ...}`. - The inline OpenRPC spec at lines 118-123 already advertises `"type": "array"`, so it stays consistent (verify after edit). ### 2. `crates/hero_agent_server/openrpc.json` - `agent.conversations.list` method (lines 266-276): change `result.schema.$ref` from `ConversationListResponse` to an inline array of `ConversationSummary`. - `ConversationListResponse` schema (lines 825-836): remove the now-orphan schema. ### 3. `crates/hero_agent_server/openrpc.client.generated.rs` - Auto-generated from `openrpc.json`. Regenerate after step 2. Expected diff: `ConversationListResponse` struct disappears; `AgentConversationsListOutput` becomes a bare `Vec<ConversationSummary>`. ### 4. `crates/hero_agent_ui/static/js/dashboard.js` - `loadConversations` (lines 104-127): already correctly checks `Array.isArray(convs)`. After server fix, works without modification. - `createConversation` (lines 136-152): after `data.id` is received, replace the manual `currentConversationId = data.id; loadConversations(); loadConversationMessages(data.id);` block with `selectConversation(data.id)` so label, sidebar highlight, and message pane all update through one path. ### 5. `scripts/smoke-test.sh` - Lines 189-194: assertion `if echo "$resp" | grep -q "conversations"` will no longer match a bare array. Update to assert the response starts with `[`, matching the existing `/api/jobs` assertion pattern. ### 6. `tests/browser/chat_ui_test.md` - Line 53: tighten "Array/object with conversations" to "Array of conversation summaries". ## Step-by-Step Implementation Plan ### Step 1 — Change `list_conversations` to return a bare array - File: `crates/hero_agent_server/src/routes.rs` - Replace the final `Json(serde_json::json!({ "conversations": conversations }))` with `Json(serde_json::json!(conversations))`. - Dependencies: none. ### Step 2 — Update `openrpc.json` schema for `agent.conversations.list` - File: `crates/hero_agent_server/openrpc.json` - In the method entry, change result schema to `{"type":"array","items":{"$ref":"#/components/schemas/ConversationSummary"}}`. - Remove the now-unused `ConversationListResponse` component schema. - Dependencies: none (independent of step 1, but they ship together). ### Step 3 — Regenerate the OpenRPC client inspection file - File: `crates/hero_agent_server/openrpc.client.generated.rs` - Trigger a build of `hero_agent_server` to refresh the inspection copy via the `openrpc_client!` macro. - Dependencies: step 2. ### Step 4 — Wire `createConversation` through `selectConversation` - File: `crates/hero_agent_ui/static/js/dashboard.js` - In `createConversation`, after `if (data.id) {`, replace the body with a single call: `selectConversation(data.id);` - Dependencies: none. Independent of server-side fix. ### Step 5 — Update smoke-test assertion - File: `scripts/smoke-test.sh` - Lines 189-194: change `grep -q "conversations"` to assert array shape (`[`), update messages to mention "array". - Dependencies: step 1. ### Step 6 — Tighten chat UI test documentation - File: `tests/browser/chat_ui_test.md` - Line 53: "Array/object with conversations" -> "Array of conversation summaries". - Dependencies: step 1. ### Step 7 — Build, run smoke tests, and manual repro - Build the workspace. - Run `scripts/smoke-test.sh` to verify the new assertion holds. - Manual repro: open the Chat tab, create a conversation via `+`, confirm sidebar lists/highlights it, label updates, chat area shows welcome state. ## Acceptance Criteria - [ ] `GET /api/conversations` returns a JSON array (bare `[...]`), not an object. - [ ] The inline OpenRPC spec at routes.rs:118-123 and the static `openrpc.json` agree: result is `array`. - [ ] `openrpc.json` no longer references `ConversationListResponse`; the orphan schema is removed. - [ ] `openrpc.client.generated.rs` is regenerated and reflects the new array shape. - [ ] In the UI, clicking `+` in the Chat sidebar creates a conversation AND immediately: - [ ] adds it to the sidebar list, - [ ] highlights it as the active conversation, - [ ] sets `#chat-conversation-label` to the new conversation ID, - [ ] swaps the chat area to the welcome state for an empty conversation. - [ ] `loadConversations` correctly renders existing conversations on dashboard load. - [ ] `scripts/smoke-test.sh` passes with the updated assertion. - [ ] `scripts/browser-mcp-test.sh` test 4.5 and test 6.2 still pass. - [ ] Manual repro from the issue body confirms all observed bugs are fixed. ## Notes ### Risks / consumers - **OpenRPC generated client**: `ConversationListResponse` and `AgentConversationsListOutput` will change shape. A repo-wide grep shows NO consumers outside the generated file itself — inspection-only. Safe. - **`agent.conversations.list` JSON-RPC method**: the inline OpenRPC spec at routes.rs:119-123 already advertises `"type": "array"` (already inconsistent with the REST handler today). The dispatcher does NOT actually implement this method — calls fall through to "Method not found". No live RPC consumer depends on the wire shape today. Safe. - **Smoke test**: must be updated in the same commit (line 190 greps for the literal `"conversations"` substring). - **Browser MCP test**: already accepts both `conversations|\[`, so it keeps passing. Optional cleanup only. ### Why server-side fix is correct - Consistent with `GET /api/conversations/:id/messages`, which already returns a bare array. - Frontend code and OpenRPC inline spec already EXPECT an array. Aligning the REST handler removes the inconsistency in two places at once. - No external consumers beyond the auto-generated client. ### Edge case - `selectConversation(id)` uses `id` as the label text. For a brand-new conv, the label shows the UUID. Friendlier labels (e.g. `data.title`) are an unrelated UX improvement and out of scope.
rawan commented 2026-04-26 10:41:01 +00:00
Author
Member
Copy link

Test Results

Command: cargo test --workspace

  • Total: 86
  • Passed: 86
  • Failed: 0
  • Ignored: 0

All tests passed across the workspace (hero_agent: 76, hero_agent integration: 2, hero_agent_server: 8).

## Test Results Command: `cargo test --workspace` - Total: 86 - Passed: 86 - Failed: 0 - Ignored: 0 All tests passed across the workspace (hero_agent: 76, hero_agent integration: 2, hero_agent_server: 8).
rawan commented 2026-04-26 10:48:24 +00:00
Author
Member
Copy link

Implementation Summary

All steps from the approved spec have been completed on branch development_fix_chat_sidebar_create_conv.

Files modified

  • crates/hero_agent_server/src/routes.rs — list_conversations now returns a bare JSON array instead of {"conversations": [...]}.
  • crates/hero_agent_server/openrpc.json — agent.conversations.list result schema changed to an inline array of ConversationSummary; the orphan ConversationListResponse schema was removed. JSON validates cleanly.
  • crates/hero_agent_server/openrpc.client.generated.rs — regenerated by the openrpc_client! macro. ConversationListResponse is gone; AgentConversationsListOutput is now a #[serde(transparent)] newtype wrapping Vec<ConversationSummary>.
  • crates/hero_agent_ui/static/js/dashboard.js — createConversation now delegates to selectConversation(data.id) after the POST succeeds, so the sidebar highlight, #chat-conversation-label, and message pane all update through one path.
  • scripts/smoke-test.sh — /api/conversations assertion updated to expect a JSON array, mirroring the /api/jobs pattern.
  • tests/browser/chat_ui_test.md — test 5.1 expected-result tightened to "Array of conversation summaries".

Test results

cargo test --workspace — 86 passed, 0 failed, 0 ignored. Workspace builds cleanly.

Notes

  • The inline OpenRPC spec at routes.rs:118-123 already advertised "type": "array", so it now agrees with the REST handler and the static openrpc.json.
  • Repo-wide grep confirmed no consumers of ConversationListResponse outside the auto-generated file.
  • The dispatcher does not implement agent.conversations.list over JSON-RPC today, so no live RPC consumer was affected by the wire-shape change.
  • Manual UI repro for the + button is still recommended once the branch is built and running locally to confirm sidebar/label/message-pane all update visibly.
## Implementation Summary All steps from the approved spec have been completed on branch `development_fix_chat_sidebar_create_conv`. ### Files modified - `crates/hero_agent_server/src/routes.rs` — `list_conversations` now returns a bare JSON array instead of `{"conversations": [...]}`. - `crates/hero_agent_server/openrpc.json` — `agent.conversations.list` result schema changed to an inline array of `ConversationSummary`; the orphan `ConversationListResponse` schema was removed. JSON validates cleanly. - `crates/hero_agent_server/openrpc.client.generated.rs` — regenerated by the `openrpc_client!` macro. `ConversationListResponse` is gone; `AgentConversationsListOutput` is now a `#[serde(transparent)]` newtype wrapping `Vec<ConversationSummary>`. - `crates/hero_agent_ui/static/js/dashboard.js` — `createConversation` now delegates to `selectConversation(data.id)` after the POST succeeds, so the sidebar highlight, `#chat-conversation-label`, and message pane all update through one path. - `scripts/smoke-test.sh` — `/api/conversations` assertion updated to expect a JSON array, mirroring the `/api/jobs` pattern. - `tests/browser/chat_ui_test.md` — test 5.1 expected-result tightened to "Array of conversation summaries". ### Test results `cargo test --workspace` — 86 passed, 0 failed, 0 ignored. Workspace builds cleanly. ### Notes - The inline OpenRPC spec at routes.rs:118-123 already advertised `"type": "array"`, so it now agrees with the REST handler and the static `openrpc.json`. - Repo-wide grep confirmed no consumers of `ConversationListResponse` outside the auto-generated file. - The dispatcher does not implement `agent.conversations.list` over JSON-RPC today, so no live RPC consumer was affected by the wire-shape change. - Manual UI repro for the `+` button is still recommended once the branch is built and running locally to confirm sidebar/label/message-pane all update visibly.
rawan commented 2026-04-26 13:37:23 +00:00
Author
Member
Copy link

Status update

The two bugs in this issue (sidebar list shape mismatch + + button not switching context) are both fixed in hero_agent and tests pass. While verifying end-to-end against the running services, three additional layers of breakage were found that block the + button from working in deployment:

# Layer Repo Status
1 Sidebar list endpoint shape hero_agent fixed (this PR)
2 createConversation -> selectConversation hero_agent fixed (this PR)
3 OSIS_URL default port 6666 (router is on 9988) hero_agent fixed (this PR)
4 hero_osis built without the ai feature (gated out of all-domains as "still under development") so hero_osis_ai RPC server never spawns hero_osis needs separate PR
5 OSIS native SDK hardcodes /rpc/{context} URL but per-domain servers only accept /rpc -> 404 on every call hero_rpc tracked in #10

The hero_agent PR is correct and self-consistent — the fixes will work end-to-end once #4 is enabled and #10 is resolved. Sub-issue #10 has full repro and proposed fix options.

## Status update The two bugs in this issue (sidebar list shape mismatch + `+` button not switching context) are both fixed in `hero_agent` and tests pass. While verifying end-to-end against the running services, three additional layers of breakage were found that block the `+` button from working in deployment: | # | Layer | Repo | Status | |---|---|---|---| | 1 | Sidebar list endpoint shape | `hero_agent` | fixed (this PR) | | 2 | `createConversation` -> `selectConversation` | `hero_agent` | fixed (this PR) | | 3 | `OSIS_URL` default port `6666` (router is on `9988`) | `hero_agent` | fixed (this PR) | | 4 | `hero_osis` built without the `ai` feature (gated out of `all-domains` as "still under development") so `hero_osis_ai` RPC server never spawns | `hero_osis` | needs separate PR | | 5 | OSIS native SDK hardcodes `/rpc/{context}` URL but per-domain servers only accept `/rpc` -> 404 on every call | `hero_rpc` | tracked in #10 | The `hero_agent` PR is correct and self-consistent — the fixes will work end-to-end once #4 is enabled and #10 is resolved. Sub-issue #10 has full repro and proposed fix options.
rawan commented 2026-04-27 08:29:14 +00:00
Author
Member
Copy link

End-to-end verified

The + button now works fully on this machine. Final state:

# Layer Repo Status
1 Sidebar list shape hero_agent done
2 createConversation -> selectConversation hero_agent done
3 OSIS_URL default port 6666 -> 9988 hero_agent done
4 OSIS_URL default path -> router root (SDK appends /hero_osis_<domain>/rpc itself) hero_agent done
5 Cargo.lock bump for hero_rpc 91c30ef -> 38a0929 (picks up the SDK URL fix that already shipped) hero_agent done
6 ai enabled in hero_osis_server all-domains so hero_osis_ai/rpc.sock is spawned hero_osis needs separate PR

Sub-issue #10 was closed — the SDK URL pattern was already corrected in hero_rpc development. hero_agent just needed a lock bump and OSIS_URL adjustment to pick it up.

Verification:

$ curl -s --unix-socket ~/hero/var/sockets/hero_agent/ui.sock \
    -X POST -d '{"title":"verify"}' http://localhost/api/conversations
{"id":"0001","title":"verify",...}

$ curl -s --unix-socket ~/hero/var/sockets/hero_agent/ui.sock \
    http://localhost/api/conversations
[{"id":"0001","title":"verify",...}]

Opening the hero_agent PR next.

## End-to-end verified The `+` button now works fully on this machine. Final state: | # | Layer | Repo | Status | |---|---|---|---| | 1 | Sidebar list shape | `hero_agent` | done | | 2 | `createConversation` -> `selectConversation` | `hero_agent` | done | | 3 | `OSIS_URL` default port `6666` -> `9988` | `hero_agent` | done | | 4 | `OSIS_URL` default path -> router root (SDK appends `/hero_osis_<domain>/rpc` itself) | `hero_agent` | done | | 5 | `Cargo.lock` bump for `hero_rpc` `91c30ef` -> `38a0929` (picks up the SDK URL fix that already shipped) | `hero_agent` | done | | 6 | `ai` enabled in `hero_osis_server` `all-domains` so `hero_osis_ai/rpc.sock` is spawned | `hero_osis` | needs separate PR | Sub-issue #10 was closed — the SDK URL pattern was already corrected in `hero_rpc development`. `hero_agent` just needed a lock bump and `OSIS_URL` adjustment to pick it up. Verification: ``` $ curl -s --unix-socket ~/hero/var/sockets/hero_agent/ui.sock \ -X POST -d '{"title":"verify"}' http://localhost/api/conversations {"id":"0001","title":"verify",...} $ curl -s --unix-socket ~/hero/var/sockets/hero_agent/ui.sock \ http://localhost/api/conversations [{"id":"0001","title":"verify",...}] ``` Opening the `hero_agent` PR next.
rawan commented 2026-04-27 08:30:48 +00:00
Author
Member
Copy link

Test Results (post-fix)

Command: cargo test --workspace

  • Total: 86
  • Passed: 86
  • Failed: 0
  • Ignored: 0

All tests pass after the lock bump and OSIS_URL change.

## Test Results (post-fix) Command: `cargo test --workspace` - Total: 86 - Passed: 86 - Failed: 0 - Ignored: 0 All tests pass after the lock bump and `OSIS_URL` change.
rawan closed this issue 2026-04-27 11:06:49 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
development_mik_nu_demo
development_chat_ui_model_dropdown
development_mik2
No results found.
Labels
Clear labels   
prio_critical

   
prio_low

   
type_bug

   
type_contact

   
type_issue

   
type_lead

   
type_question

   
type_story

   
type_task
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
rawan
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_agent#6
No description provided.