Found while working on #2001 (a v1.20.0 backup restored onto the 2.0 appliance).
What happens
In v1.20.0 the dashboard config editor serves config.reference.json merged under the host config (control_service.read_config, _deep_merge(reference, cfg)). applyEdits clones that whole merged object and commits it. A v1.20.0 config saved through the editor therefore carries the full xmrig_proxy block at its reference defaults (enabled: true, url: na.xmrvsbeast.com:4247, donor_id: auto) next to the operator's xvb.*.
When the operator has customised xvb.url or xvb.donor_id, 2.0's migrate_legacy_workers (lib/pithead/27-defaults-and-config-validation.sh) treats the untouched xmrig_proxy defaults as a conflicting 1.x setting and refuses:
config.json sets both a removed 1.x key and its replacement to different values (xvb.url and xmrig_proxy.url; xvb.donor_id and xmrig_proxy.donor_id). ...
Reproduction with the conflict filter from that function:
echo '{"xvb":{"enabled":true,"url":"eu.xmrvsbeast.com:4247","donor_id":"mine"},"xmrig_proxy":{"enabled":true,"url":"na.xmrvsbeast.com:4247","donor_id":"auto"}}' \
| jq -r --argjson ks '["enabled","url","donor_id"]' '[ ($ks[] as $k | select(((.xmrig_proxy // {}) | has($k)) and ((.xvb // {}) | has($k)) and (.xmrig_proxy[$k] != .xvb[$k])) | "xvb.\($k) and xmrig_proxy.\($k)") ] | join("; ")'
# xvb.url and xmrig_proxy.url; xvb.donor_id and xmrig_proxy.donor_id
So a DIY upgrade of such a config refuses to apply until the operator deletes xmrig_proxy by hand. A wizard restore of its backup is rejected, and the message tells the operator to edit a config.json they cannot reach at that point.
Expected
An xmrig_proxy.* value equal to its v1.x reference default is a schema default, never an operator choice. This is the same reasoning #679 applied to an empty dashboard.workers[]. The migration should drop it and never let it conflict with xvb.*; only a non-default xmrig_proxy value that differs from xvb is a real conflict. A tier-1 row covers an editor-shaped v1.20.0 config with a customised xvb.url.
Related: #1832, #1954, #2001.
Found while working on #2001 (a v1.20.0 backup restored onto the 2.0 appliance).
What happens
In v1.20.0 the dashboard config editor serves
config.reference.jsonmerged under the host config (control_service.read_config,_deep_merge(reference, cfg)).applyEditsclones that whole merged object and commits it. A v1.20.0 config saved through the editor therefore carries the fullxmrig_proxyblock at its reference defaults (enabled: true,url: na.xmrvsbeast.com:4247,donor_id: auto) next to the operator'sxvb.*.When the operator has customised
xvb.urlorxvb.donor_id, 2.0'smigrate_legacy_workers(lib/pithead/27-defaults-and-config-validation.sh) treats the untouchedxmrig_proxydefaults as a conflicting 1.x setting and refuses:Reproduction with the conflict filter from that function:
So a DIY upgrade of such a config refuses to apply until the operator deletes
xmrig_proxyby hand. A wizard restore of its backup is rejected, and the message tells the operator to edit aconfig.jsonthey cannot reach at that point.Expected
An
xmrig_proxy.*value equal to its v1.x reference default is a schema default, never an operator choice. This is the same reasoning #679 applied to an emptydashboard.workers[]. The migration should drop it and never let it conflict withxvb.*; only a non-defaultxmrig_proxyvalue that differs fromxvbis a real conflict. A tier-1 row covers an editor-shaped v1.20.0 config with a customisedxvb.url.Related: #1832, #1954, #2001.