latest release only ships hero_memory CLI — server binaries missing #3

New issue

Open

opened 2026-05-20 14:21:48 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-05-20 14:21:48 +00:00

Member

Symptom

The latest release at https://forge.ourworld.tf/lhumina_code/hero_memory/releases publishes a single asset: hero_memory-linux-musl-x86_64 (~1 MB). That's the CLI client only.

When a downstream service like hero_books (dev) tries to use this — set HERO_MEMORY_SOCKET or run hero_memory --start — the CLI happily registers hero_memory_inference, hero_memory_server, and hero_memory_ui as hero_proc jobs, but those binaries don't exist on disk, so all three crash on launch:

[hero_memory_ui | failed | job:21]
  [stderr] fatal runtime error: assertion failed: output.write(&bytes).is_ok(), aborting
[hero_memory_server | failed | job:20]
  [stderr] fatal runtime error: assertion failed: output.write(&bytes).is_ok(), aborting
[hero_memory_inference | failed | job:19]
  [stderr] fatal runtime error: assertion failed: output.write(&bytes).is_ok(), aborting

The failure mode is confusing because hero_memory --start itself returns started successfully (AllInOne) even though the child jobs immediately fail.

Expected

The latest release should publish all binaries needed for a working deployment:

hero_memory (CLI — already there)
hero_memory_inference
hero_memory_server
hero_memory_ui
hero_memory_proxy

…matching the crates in this repo. Otherwise downstreams like hero_books dev cannot smoke-test against published artifacts.

Ideally the CLI should also bail early if the required sibling binaries aren't on PATH, instead of registering jobs that crash later.

Repro

Fresh TFGrid VM:

curl -fsSL -o /usr/local/bin/hero_memory \
  https://forge.ourworld.tf/lhumina_code/hero_memory/releases/download/latest/hero_memory-linux-musl-x86_64
chmod +x /usr/local/bin/hero_memory
export PATH_ROOT=/root/hero PATH_VAR=/data/hero/var HERO_SOCKET_DIR=/data/hero/var/sockets
/usr/local/bin/hero_memory --start   # claims success
hero_proc service list                # hero_memory shown as 'failed'
hero_proc service logs hero_memory    # all three subjobs panic on stdio

## Symptom The `latest` release at https://forge.ourworld.tf/lhumina_code/hero_memory/releases publishes a single asset: `hero_memory-linux-musl-x86_64` (~1 MB). That's the CLI client only. When a downstream service like `hero_books` (dev) tries to use this — set `HERO_MEMORY_SOCKET` or run `hero_memory --start` — the CLI happily registers `hero_memory_inference`, `hero_memory_server`, and `hero_memory_ui` as hero_proc jobs, but those binaries don't exist on disk, so all three crash on launch: ``` [hero_memory_ui | failed | job:21] [stderr] fatal runtime error: assertion failed: output.write(&bytes).is_ok(), aborting [hero_memory_server | failed | job:20] [stderr] fatal runtime error: assertion failed: output.write(&bytes).is_ok(), aborting [hero_memory_inference | failed | job:19] [stderr] fatal runtime error: assertion failed: output.write(&bytes).is_ok(), aborting ``` The failure mode is confusing because `hero_memory --start` itself returns `started successfully (AllInOne)` even though the child jobs immediately fail. ## Expected The `latest` release should publish all binaries needed for a working deployment: - `hero_memory` (CLI — already there) - `hero_memory_inference` - `hero_memory_server` - `hero_memory_ui` - `hero_memory_proxy` …matching the crates in this repo. Otherwise downstreams like `hero_books` dev cannot smoke-test against published artifacts. Ideally the CLI should also `bail` early if the required sibling binaries aren't on PATH, instead of registering jobs that crash later. ## Repro Fresh TFGrid VM: ```bash curl -fsSL -o /usr/local/bin/hero_memory \ https://forge.ourworld.tf/lhumina_code/hero_memory/releases/download/latest/hero_memory-linux-musl-x86_64 chmod +x /usr/local/bin/hero_memory export PATH_ROOT=/root/hero PATH_VAR=/data/hero/var HERO_SOCKET_DIR=/data/hero/var/sockets /usr/local/bin/hero_memory --start # claims success hero_proc service list # hero_memory shown as 'failed' hero_proc service logs hero_memory # all three subjobs panic on stdio ```

zaelgohary self-assigned this

2026-05-20 14:21:58 +00:00

No labels

No milestone

No project

No assignees

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_memory#3

No description provided.

Rows
Columns