Multiple unprotected `.map()` calls on session data causing runtime errors and "Failed to load sessions"

[futurovisionarioai-agent]

Environment

• Hermes Agent: v0.17.x
• Hermes Workspace: Latest (Docker)
• Setup: Docker Compose + Traefik on Linux VPS (Hostinger)

Problem

When using Hermes Workspace, the following errors appear frequently:

• Cannot read properties of undefined (reading 'map')
• NotFoundError: Failed to execute 'insertBefore' on 'Node'
• "Failed to load sessions" in the sidebar and UI components

Verified Facts

• /api/sessions returns HTTP 200 with valid JSON.
• One specific unprotected .map() location (usage.sessions) was patched in /app/dist/server/assets/router-DxziTUUJ.js. The patch was successfully applied and verified, but the errors persisted.
• Multiple other locations in the same bundle file execute .map() and .length directly on sessions, sessions2, and usage.sessions without defensive checks.
• Backend communication, database integrity (state.db), and environment variables have been ruled out.

Steps to Reproduce

1. Deploy Hermes Workspace via Docker Compose.
2. Open the application.
3. Interact with any UI that displays session lists (sidebar, chat panel, sessions drawer).
4. The errors appear during rendering.

Expected Behavior

Session lists should render without JavaScript errors when valid data is returned by the API.

Actual Behavior

The frontend crashes when trying to iterate over session data that is undefined in some render paths, causing both TypeErrors and React DOM reconciliation failures.

What Was Already Tried

A minimal, reversible patch was applied to one of the unprotected .map() calls. While the patch was confirmed to be in place, the issue remained, indicating multiple unprotected call sites exist in the frontend bundle.

Conclusion

The root cause appears to be in the Hermes Workspace frontend. Several components render session data without sufficient null/undefined guards before calling array methods.

Request to Maintainers
The backend and Agent communication have been thoroughly verified. The problem seems isolated to the frontend bundle of Hermes Workspace. Adding defensive checks (or ensuring session data is always normalized before rendering) in the relevant components would likely resolve the issue.

[Guizermklgre45845]

Confirming this in production (Docker :latest on a Hostinger VPS) — and the two routes that actually throw

I hit this exact issue and traced it to two server routes that assume their data-access helper always returns an array. When the helper resolves undefined, the route throws before building a response.

Environment

• Docker image ghcr.io/outsourc-e/hermes-workspace:latest on a Hostinger VPS
• Server bundle: dist/server/assets/router-*.js

Symptoms

• GET /api/sessions → 500 — Cannot read properties of undefined (reading 'map')
• GET /api/history → 500 — Cannot read properties of undefined (reading 'length')

Because /api/sessions runs during the authenticated render, the whole workspace UI fails to load ("Failed to load sessions"). Once a session exists, /api/history then breaks message loading.

Root cause

1. GET /api/sessions maps over the sessions helper result immediately. When the helper resolves undefined, .map(...) throws.
2. GET /api/history awaits the messages helper and reads .length on the result. When the helper resolves undefined, .length throws.

Fix (defensive ?? [] on both routes)

• /api/sessions: guard the value with ?? [] before .map(...).
• /api/history: guard the awaited messages with ?? [] before reading .length.

Both are one-line, backward-compatible guards that fall back to an empty array — matching how empty results are already handled elsewhere in the codebase.

Verification

After applying both guards and restarting the container:

• /api/sessions and /api/history both return 200
• Sessions create and load
• Message history persists
• The agent replies normally end-to-end

[outsourc-e]

Status update: current main already normalizes both crash surfaces reported here — session lists go through normalizeSessions() (src/screens/chat/utils.ts:220, returns [] for any non-array) and the usage meter goes through parseSessionStatus() which defaults sessions to []. The bundle referenced in the report (router-DxziTUUJ.js) predates these guards. Please pull the latest image (or build from main after today's merges) and reopen if you can still reproduce — a fresh console trace with the new bundle hash would pinpoint any remaining unguarded path.