fix: preserve per-project config.json (ports) across both init and update#38
Open
mann1x wants to merge 2 commits into
Open
fix: preserve per-project config.json (ports) across both init and update#38mann1x wants to merge 2 commits into
mann1x wants to merge 2 commits into
Conversation
…ostack#37) `update.ts` was unconditionally copying `src/templates/config.json` over every registered project's `.wolf/config.json`. That file is not template content — it carries each project's daemon port, dashboard port, scan intervals, and exclude patterns. Overwriting it across all projects in one shot resets every registered project to the same defaults (`daemon=18790`, `dashboard=18791`), so only the first daemon to start binds and the rest crash-loop on `EADDRINUSE`. Move `config.json` from `ALWAYS_OVERWRITE` to `USER_DATA_FILES`. It is still included in `BACKUP_FILES` via the spread, so `openwolf restore` can still recover it. Reproduced on Linux (PVE 7) and Windows 11. After local apply, ten projects on one host kept their unique ports through a simulated update; pre-patch, all ten fell to defaults inside one second. No behavior change for `OPENWOLF.md` or `reframe-frameworks.md` — those remain protocol-doc overwrites.
openwolf init listed config.json in ALWAYS_OVERWRITE, so every re-init (and upgrade) re-stamped the file with the hardcoded default ports (daemon 18790 / dashboard 18791). With more than one project registered, all daemons then tried to bind the same dashboard port; only the first to start won and the rest crash-looped on EADDRINUSE. - Remove config.json from ALWAYS_OVERWRITE; handle it via reconcileConfig(). - reconcileConfig: create-if-missing only; an existing config is left untouched so re-init never resets a user's ports. - On a fresh create, allocate the next free daemon/dashboard port pair by scanning other registered projects' config.json, so two fresh inits no longer collide. Pairs with the update.ts change on this branch (config.json moved to USER_DATA_FILES) so neither init nor update can reset per-project ports.
openwolf update (fixes #37)
Author
|
Pushed a second commit ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On a host with more than one OpenWolf project registered, every project's
daemon tries to bind the same dashboard port and all but the first
crash-loop on
EADDRINUSE. Root cause is thatconfig.json— which holds theper-project
openwolf.daemon.port/openwolf.dashboard.port— was beingforce-overwritten with the hardcoded template defaults (
18790/18791) byboth CLI commands:
openwolf updatelistedconfig.jsoninALWAYS_OVERWRITE, so everyupdate reset every registered project back to
18790/18791. (Tracked in openwolf update overwrites every project's config.json with template defaults — mass port collision #37.)openwolf initalso listedconfig.jsonin its ownALWAYS_OVERWRITE,so any re-init/upgrade reset it too — and there was no port allocation at
all, so even two fresh
inits on the same host produced identical ports.Observed in the wild: three projects on one host, all stamped
18791; after areboot only the first daemon bound and the other two sat
erroredwiththousands of restart attempts (
EADDRINUSE :::18791).Fix
config.jsonis user data, not a template, and is now treated as such inboth commands:
update.ts— moveconfig.jsonout ofALWAYS_OVERWRITEintoUSER_DATA_FILES(still backed up byrestore). An existing config is neveroverwritten on update.
init.ts— removeconfig.jsonfromALWAYS_OVERWRITE; handle it via anew
reconcileConfig():a re-init never resets a user's ports;
daemon/dashboardport pair byscanning other registered projects'
config.json, so two fresh inits nolonger collide.
No behavior change for single-project users; multi-project hosts stop
colliding.
tsc --noEmitclean.Verification
Deployed the built
init.js+update.jsto a live multi-project host and ranopenwolf update: all three projects' custom dashboard ports survived(previously they were reset to
18791). Output confirms templates updated wereonly
OPENWOLF.md, reframe-frameworks.md—config.jsonuntouched.Closes #37 (and the
init-side half of the same defect).