hero_proc_server 0.4.4 hard-refuses to start without FORGE_TOKEN + WEBROOT #111

New issue

Open

opened 2026-05-20 09:44:06 +00:00 by zaelgohary · 1 comment

zaelgohary commented

2026-05-20 09:44:06 +00:00

Member

hero_proc_server 0.4.4 exits with error: FORGE_TOKEN environment variable is required but not set (and the same for WEBROOT) before the supervisor accepts any connections.

FORGE_TOKEN is only consumed by the secret.pull / secret.push RPCs (crates/hero_proc_server/src/rpc/secret.rs).
HEAD already relaxes this to a startup warning (crates/hero_proc_server/src/server.rs: forge_token = unset (forge ops will fail until set via env or 'secret pull')).
0.4.4 is the only hero_proc version whose registry artifacts (-linux-amd64) match the slides deploy scaffolding's fetch names, so users who follow the documented deploy hit this immediately.

Downstream impact: hero_slides deploy scaffolding (lhumina_code/hero_slides#72) now has to bake an opaque FORGE_TOKEN requirement into its app.env.example for a feature most operators don't need.

Fix: backport the warn-instead-of-error change to a 0.4.5 (or a 0.4.4-fix1) and republish.

hero_proc_server `0.4.4` exits with `error: FORGE_TOKEN environment variable is required but not set` (and the same for `WEBROOT`) before the supervisor accepts any connections. - `FORGE_TOKEN` is only consumed by the `secret.pull` / `secret.push` RPCs (`crates/hero_proc_server/src/rpc/secret.rs`). - HEAD already relaxes this to a startup warning (`crates/hero_proc_server/src/server.rs`: `forge_token = unset (forge ops will fail until set via env or 'secret pull')`). - 0.4.4 is the only hero_proc version whose registry artifacts (`-linux-amd64`) match the slides deploy scaffolding's fetch names, so users who follow the documented deploy hit this immediately. Downstream impact: hero_slides deploy scaffolding (lhumina_code/hero_slides#72) now has to bake an opaque `FORGE_TOKEN` requirement into its `app.env.example` for a feature most operators don't need. Fix: backport the warn-instead-of-error change to a 0.4.5 (or a `0.4.4-fix1`) and republish.

zaelgohary self-assigned this

2026-05-20 09:44:53 +00:00

zaelgohary referenced this issue from a pull request that will close it,

2026-05-20 11:02:21 +00:00

fix(server): warn instead of exit when FORGE_TOKEN/WEBROOT unset (0.4.5) #112

sameh-farouk commented

2026-05-21 11:08:27 +00:00

Member

Code fix landed; binary refresh PARTIAL — close once arm64/macOS catch up.

Confirmed crates/hero_proc_server/src/server.rs:51-65 now:

Logs FORGE_TOKEN unset as a startup warning instead of refusing to start
Falls back to WEBROOT="http://127.0.0.1:9998/" when unset

Customer-install on x86_64 Linux already gets this fix — latest release's hero_proc-linux-musl-x86_64 asset was refreshed today (2026-05-21T09:20:54Z by the canonical lab-publish.yaml workflow on push to development).

But the same release's hero_proc-linux-musl-arm64 and hero_proc-macos-arm64 assets are still from 2026-05-17, i.e. pre-fix. lab-publish.yaml is x86_64-only by design; arm64+macOS need their own publish workflow.

Leaving open until the multi-arch republish gap is addressed (or this defect's customer impact is judged to be x86_64-Linux-only).

**Code fix landed; binary refresh PARTIAL — close once arm64/macOS catch up.** Confirmed `crates/hero_proc_server/src/server.rs:51-65` now: - Logs `FORGE_TOKEN unset` as a startup warning instead of refusing to start - Falls back to `WEBROOT="http://127.0.0.1:9998/"` when unset Customer-install on x86_64 Linux already gets this fix — `latest` release's `hero_proc-linux-musl-x86_64` asset was refreshed today (2026-05-21T09:20:54Z by the canonical `lab-publish.yaml` workflow on push to development). But the same release's `hero_proc-linux-musl-arm64` and `hero_proc-macos-arm64` assets are still from 2026-05-17, i.e. pre-fix. `lab-publish.yaml` is x86_64-only by design; arm64+macOS need their own publish workflow. Leaving open until the multi-arch republish gap is addressed (or this defect's customer impact is judged to be x86_64-Linux-only).