diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-05 19:48:10 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-05 19:48:10 +0200 |
| commit | fff1974edf19cf1186e0f49da5f8a4d237bcb13e (patch) | |
| tree | 3c623c6253cd005773546b207f4749e98151a7b5 /docs/per-node-identity-v1.md | |
| parent | 5b4c4df56bcc795be6a8416987e2d91f91ea14ba (diff) | |
| download | meshbay-fff1974edf19cf1186e0f49da5f8a4d237bcb13e.tar.gz | |
fix(win): finish the desktop setup flow — node-key link + service task
Two independent breaks in the Windows first-run path:
- node:start's win32 branch never linked the node's Ed25519 key to the hub
account, so the daemon sat at waiting_for_account and the Create Group
wizard span on "Detecting local node…" for ever — the only way through
was pasting the key by hand on the Profile page. The Linux branch has
always done this inline; factor it into linkNodeKeyAndAwaitRunning() and
call it from win32 too. PUT /v1/users/me/node_key overwrites, so this
also recovers an account still carrying a previous machine's node key.
- service.ps1's install branch did `$action = New-ScheduledTaskAction`,
shadowing its own [ValidateSet(...)][string]$Action parameter (PowerShell
variable names are case-insensitive). The CimInstance was coerced to the
string "MSFT_TaskExecAction", Register-ScheduledTask -Action rejected it,
and "background service" mode never created the task — reproduced live.
Rename the locals to $taskAction / $bootTrigger / $taskPrincipal.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Diffstat (limited to 'docs/per-node-identity-v1.md')
0 files changed, 0 insertions, 0 deletions