fix(workspace): ship Python backend in the image, not the ConfigMap (fixes #430 + Mission Control 404)#431
Merged
Conversation
…ap (#430) The workspace `browser-config` ConfigMap embedded the entire Python backend (server.py + memory/skills/adapters/gateway/mcp_* — ~992 KiB across 32 files) via `{{ .Files.Get }}`. As the code grew it crossed BOTH 1 MiB limits: - the rendered ConfigMap object hit ~1086 KiB (> 1 MiB ConfigMap cap), and - the Helm release Secret (rendered manifest + bundled chart files) hit ~1 MiB, so `helm upgrade` started failing for every workspace: Secret "sh.helm.release.v1.<ws>.vN" ... Too long: may not be more than 1048576 bytes This silently froze every workspace's ConfigMap-delivered server.py — self-serve updates only patched the *image*, so e.g. a v1.41.1 image still ran a v1.40.1 server.py (no Mission Control -> /api/missioncontrol/queue 404). Fix — bake the backend into the image and drop it from the chart: - devlaptop/Dockerfile: COPY server.py + memory/ skills/ adapters/ (+ the top-level mcp_*/gateway/seed_*/harness/etc.) into /opt/browser-src. - start.sh: seed /tmp/browser and /home/dev/.claude-memory from /opt/browser-src (a `cp -a` tree copy) instead of unpacking flat /browser-config ConfigMap keys. - Delete templates/browser-configmap.yaml; remove its mount/volume/checksum from the Deployment. Code changes now roll the pod via the image tag. - .helmignore the backend .py so Helm no longer bundles it into the chart — this is what actually shrinks the release Secret. Packaged chart: ~1 MB -> 64 KiB. Consequence: backend changes ship via an image rebuild (a release), not a config-only `make ship-config`. Every release already rebuilds the image, so this also fixes the long-standing "image updated but backend stale" class of bug — an image update now delivers backend code. Verified: helm lint clean; 106 helm unittests green (2 updated for the new path); `helm template` renders with no browser-config ConfigMap/mount; a local COPY+seed simulation imports server/hypervisor_session/gateway/mcp_*/memory/ skills/adapters cleanly and confirms the missioncontrol route is present.
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.
Fixes #430. Also fixes the Mission Control
/api/missioncontrol/queue404 users see after updating.Problem
The
browser-configConfigMap embedded the whole Python backend (server.py +memory/skills/adapters/gateway.pymcp_*— ~992 KiB, 32 files) via{{ .Files.Get }}. As the code grew it crossed both 1 MiB limits:so
helm upgradebegan failing for every workspace:That silently froze every workspace's ConfigMap-delivered
server.py— self-serve/admin updates only ever patched the image, so a v1.41.1 image still ran a v1.40.1 server.py → no Mission Control → the 404.make ship/make deploy/self-serve reconcile were all blocked.Fix — bake the backend into the image, drop it from the chart
devlaptop/Dockerfile:COPYserver.py +memory/ skills/ adapters/(+ top-levelmcp_*/gateway/seed_*/harness/…) into/opt/browser-src.start.sh: seed/tmp/browser+/home/dev/.claude-memoryfrom/opt/browser-src(acp -atree copy) instead of unpacking flat/browser-configConfigMap keys.browser-configmap.yaml; remove its mount/volume/checksum from the Deployment. Code changes now roll the pod via the image tag..helmignorethe backend.pyso Helm stops bundling it into the chart — this is what actually shrinks the release Secret. Packaged chart: ~1 MB → 64 KiB.Consequence (deliberate)
Backend changes now ship via an image rebuild (a release), not a config-only
make ship-config. Every release already rebuilds the image — and this also kills the recurring "image updated but backend stale" bug class (#240/#307/#319/#430): an image update now delivers backend code by construction.Verification
helm lintclean; 106 helm unittests green (2 updated for the new/opt/browser-srcpath);helm templaterenders with no browser-config ConfigMap/mount/volume.server,hypervisor_session,gateway,mcp_*, and thememory/skills/adapterspackages all import cleanly, andserver.pycontains theapi/missioncontrolroute.COPY(final gate).After merge
Cut a release; workspaces can
helm upgradeagain and self-serve/fleet updates deliver the currentserver.py— Mission Control appears and the 404 is gone.🤖 Generated with Claude Code