Symptom
Every hub engine boot logs two ERROR-level message=failed ref=err_* lines ~1s after init, on two different builds (so not a canary artifact — it's in current main's engine or the shared base):
timestamp=2026-10-04T09:07:22.947Z level=ERROR message=failed ref=err_13a5fca6 error="TypeError: undefined is not an object (evaluating 'a.name')"
timestamp=2026-10-04T12:03:59.403Z level=ERROR message=failed ref=err_20859169 error="TypeError: undefined is not an object (evaluating 'a.name')"
Minified stack (both builds): resolve (chunk-…js:2:1659) through three nested map frames into Server.listen frames — the same misleading Server.listen naming that appeared in the October per-request errors (FileSystem.realPath PlatformErrors at identical frames), i.e. a boot-time pass iterating a collection where one entry lacks the expected .name.
Impact
Boot-only, non-fatal: the engine serves fine afterward (all endpoints 200, sessions work). Observed on boots of both 87bd160e… (Oct 2 build) and c7d98af5… (current main + #1550, Oct 4). Log evidence: ~/.local/share/opencode/log/opencode.log on erlich, runs 8bef6557 (09:07Z) and 647edd2d (12:03Z).
Suggested triage
Reproduce locally: boot the built engine against the hub's config (OPENCODE_CONFIG_CONTENT from ~/.amico/server/opencode-config-content.json spliced, agents staged in ~/.config/opencode/agents) and break on the resolve frame. Suspect: an iteration over agents/modes/providers where a config entry (a markdown agent card with frontmatter quirks, or a config key with no name) yields undefined. Also worth demoting/changing the log shape if it's a known-benign boot probe — ERROR-level noise at every boot trains people to ignore the log.
Symptom
Every hub engine boot logs two ERROR-level
message=failed ref=err_*lines ~1s after init, on two different builds (so not a canary artifact — it's in current main's engine or the shared base):Minified stack (both builds):
resolve (chunk-…js:2:1659)through three nestedmapframes intoServer.listenframes — the same misleadingServer.listennaming that appeared in the October per-request errors (FileSystem.realPathPlatformErrors at identical frames), i.e. a boot-time pass iterating a collection where one entry lacks the expected.name.Impact
Boot-only, non-fatal: the engine serves fine afterward (all endpoints 200, sessions work). Observed on boots of both
87bd160e…(Oct 2 build) andc7d98af5…(current main + #1550, Oct 4). Log evidence:~/.local/share/opencode/log/opencode.logon erlich, runs8bef6557(09:07Z) and647edd2d(12:03Z).Suggested triage
Reproduce locally: boot the built engine against the hub's config (
OPENCODE_CONFIG_CONTENTfrom~/.amico/server/opencode-config-content.jsonspliced, agents staged in~/.config/opencode/agents) and break on theresolveframe. Suspect: an iteration over agents/modes/providers where a config entry (a markdown agent card with frontmatter quirks, or a config key with no name) yields undefined. Also worth demoting/changing the log shape if it's a known-benign boot probe — ERROR-level noise at every boot trains people to ignore the log.