admin-config-tool's spec.json blocked_on and tasks.md both still described
the OP_upgradeConfig dispatch-gate defect as an open blocker. It was fixed
2026-07-25 (bug-1468, commit 959b0cda) by config-upgrade-snapshot task 8.6,
which independently hit the same wall building a live OP_upgradeConfig
sender -- the fix's own comment in cluster.c already cross-references this
spec. The controller-side path has since been exercised live and
successfully many times via config-upgrade-snapshot's --config-upgrade
soak. All 23 admin-config-tool tasks are already [x]; this was pure
tracking-metadata debt, not a reopened implementation gap.
Also appends a cross-spec gap analysis (admin-config-tool x
config-upgrade-snapshot x clusterconfig-schema-split) to all three specs'
research.md, confirming clean schema integration between the latter two
and flagging the one remaining real gap: a new commit-timeout issue in
config-upgrade-snapshot task 8.6's force-elect step, surfaced now that
bug-1477 is fixed, not yet root-caused.
34 lines
2 KiB
JSON
34 lines
2 KiB
JSON
{
|
|
"feature_name": "admin-config-tool",
|
|
"created_at": "2026-07-06T01:30:00Z",
|
|
"updated_at": "2026-07-22T14:50:00Z",
|
|
"language": "en",
|
|
"phase": "implementation-complete",
|
|
"approvals": {
|
|
"requirements": {
|
|
"generated": true,
|
|
"approved": true
|
|
},
|
|
"design": {
|
|
"generated": true,
|
|
"approved": true
|
|
},
|
|
"tasks": {
|
|
"generated": true,
|
|
"approved": true
|
|
}
|
|
},
|
|
"ready_for_implementation": true,
|
|
"blocked_on": [
|
|
"RESOLVED 2026-07-25 (bug-1468, commit 959b0cda): controller OP_upgradeConfig dispatch defect (cluster.c) -- myreq_handler's dispatch guard was inverted (introduced by commit fd93997f, 2026-05-31), rejecting the only role that could ever legitimately reach it and making handle_upgrade_config() permanently unreachable from any network client. Fixed by config-upgrade-snapshot task 8.6 (which independently hit the same wall building a live OP_upgradeConfig sender). The controller-side path this blocker described has since been exercised live and successfully many times via config-upgrade-snapshot's --config-upgrade soak. push_config() itself (xceadmin's TLS/redirect/framing code) remains mock-tested only -- a live `xceadmin config push` run against a deployed cluster would give first-hand confirmation of the CLI's own wire code, but the blocking condition (dispatch unreachable) no longer exists.",
|
|
"RESOLVED 2026-07-22 (bug-1461, commit e53c086): controller.capnp's struct Data shadowed the capnp builtin blob type, miscompiling UpgradeConfigRequest.sha256/.bytes — fixed at the schema root (renamed to XceData), unblocking push_config()'s request construction. The dispatch defect above (bug-1468) is a separate issue and is now ALSO resolved (see entry above) — push_config() remains mock-tested only, no live xceadmin-specific E2E run yet, but nothing blocks one."
|
|
],
|
|
"gitea": {
|
|
"milestone_id": 1,
|
|
"issues": {
|
|
"requirements_design": 22,
|
|
"implementation": 23,
|
|
"validation": 24
|
|
}
|
|
}
|
|
}
|