Org config pushes old central host (hypaware.hyperparam.app), identity check refuses it, daemon exits 75

Open
  • Is something wrong?
#2,513 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, node.js
Domain
authentication, backend

Research direction

Start with src/core/remote/builtin_remotes.js and central/src/identity_client.js, which the issue identifies as the alias-handling and raw-comparison paths. Then trace where the server supplies sinks.central.config.url; that location is not identified here. The scope spans client identity checks, server-published org config, and daemon recovery; done means a fresh login and daemon run keep the central sink healthy, and no served config contains the old host.

Written by the indexing model from the issue text.

Description

neutral:fix neutral:review

Summary

After hyp remote login against https://api.hypaware.ai, the org config served to the host sets sinks.central.config.url = "https://hypaware.hyperparam.app". The central identity check compares that against the persisted identity's central_url (https://api.hypaware.ai) as raw strings, refuses to load, and the central sink fails to materialize. The processing worker exits 75 and takes the whole daemon down, gateway included.

Environment: hypaware 1.40.0, Node 22.22.0, Linux cloud container (no systemd), daemon run with hyp daemon run. Org hyperparam.

Repro

  1. npm i -g [email protected]
  2. hyp setup --yes --no-daemon
  3. hyp remote login --no-browser --no-daemon (as a member of the hyperparam org)
  4. hyp daemon run
  5. Within about 1s: processing.exited code 75, gateway.stopped. hyp status shows:
sink 'central' not materialized [sink_materialize_failed]: identity central URL mismatch: persisted identity was minted by https://api.hypaware.ai but the configured central server is https://hypaware.hyperparam.app. Re-run `hyp remote login` against the new server to enroll this host

Evidence from the host:

  • plugins/@hypaware/central/identity.json: central_url = https://api.hypaware.ai, origin = login
  • config-control/config.a.json (from login): sinks.central.config.url = https://api.hypaware.ai
  • config-control/config.b.json (org config pulled at daemon start, applied on probation): sinks.central.config.url = https://hypaware.hyperparam.app

Causes and fixes

  1. Client: alias not applied (fix in PR). BUILTIN_ORIGIN_ALIASES in src/core/remote/builtin_remotes.js already folds hypaware.hyperparam.app into api.hypaware.ai, and its docstring says every same-server comparison reads through it. central/src/identity_client.js compares raw strings in both the load-time mismatch check and mintChanged().
  2. Server: org config still names the old host. Find where the served config sets sinks.central.config.url (org record, default template, or a server env var) and change it to https://api.hypaware.ai, or omit it so the client keeps the URL it signed in against. Check every org, not just hyperparam. Even with fix 1, the sink would send to the old host, which environments that allowlist only api.hypaware.ai block (verified: 403 from the egress proxy).
  3. Server: guard on publish. Reject or warn on an org config whose central URL differs from the URL the server issues identities under.
  4. Client: a bad pushed config takes the daemon down. Probation existed (previous_slot a), but the process exited before any rollback, and exit 75 stopped the gateway too. With proxy_mode: true, every client routed through the gateway loses model API access. Expected: keep running on the previous slot, or roll back right away. Worth confirming whether rollback ever runs when the daemon is dead.
  5. Client: misleading remedy. The error says to re-run hyp remote login "against the new server", but hyp remote login takes a remote name, not a URL, so that hint can't be followed.
  6. Ops: revoke the gateway token for gw-348d71329a9f0243. It was exposed while debugging.

Done when

  • A fresh login plus hyp daemon run stays healthy and hyp status --verbose lists the central sink.
  • Nothing the server serves contains hypaware.hyperparam.app.
Dominant language
JavaScript
Stars
11
Forks
0
Avg merge
2h 55m
Merged PRs (30d)
294

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hyparam/hypaware

All issues in hyparam/hypaware

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.