Control plane should not hand a configRef to a harness that cannot apply it
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
Research direction
Start with the ordering problem in deploy/k8s/setup.sh, which applies the supervisor, control plane and relay in one kubectl apply, and with the manual procedure in docs/operations/upgrades.md. Read ADR-0038 and PR #501 for the upgrade-order rule, and check how the harness reports its version on /health via X-Moca-Version. Done means a turn naming a bundle on a harness without bundle support fails with a clear error, and the manual ordering rule can be removed from the docs.
Written by the indexing model from the issue text.
Description
Follow-up from the upgrade-order discussion on PR #501 and the change policy.
Problem. Config bundles require the harness to be upgraded before the control plane (ADR-0038). An older harness ignores configRef, so a turn runs without the user's promoted skills and reports no error. Nothing enforces the order: deploy/k8s/setup.sh applies the supervisor, control plane and relay in one kubectl apply, and they use the same image, so they roll in parallel. Today the only mitigation is a manual pause/resume procedure in the operations docs (docs/operations/upgrades.md, unverified).
Proposal. Make the failure visible instead of silent. For example, the harness already returns X-Moca-Version on /health; the control plane (or the exchange) could refuse to issue a configRef, or fail the turn with a clear error, when the harness it serves does not advertise bundle support. A suggestion, not a design.
Out of scope. Splitting the image.
Acceptance. A turn that names a bundle on a harness without bundle support fails loudly (not silently without skills), and the manual ordering rule can be dropped from the upgrade docs.
- Dominant language
- TypeScript
- Stars
- 4
- Forks
- 9
- Avg merge
- 9h 2m
- Merged PRs (30d)
- 138
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rossoctl/moca
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
rossoctl/moca#421 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
cline/cline#15327 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
LogicLabs-OU/OpenArchiver#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bigcapitalhq/bigcapital#1545 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day