Omar Sobh
b569688e04
The seed-mount approach didnt work: even with the shared runtimes data dir bind-mounted, a fresh gateway instance mints a new pairing key and requires re-pairing. The topology_worker connect returned 401 forever. New approach — per-mission gateways self-pair: - Provisioner tails container logs after start, extracts the X-Pairing-Code from the boot banner - Persists it on missions.runtime_pairing_code (migration 0059) - topology_worker constructs ZeroClawDriveExecutor with THAT code via from_env_for_gateway_with_code, which triggers the lazy /pair handshake on first turn and caches the returned bearer Drops the shared-runtime data-dir mount — each per-mission gateway now owns its own state, restoring the C3 isolation guarantee.
14 lines
596 B
SQL
14 lines
596 B
SQL
-- Per-mission ZeroClaw pairing code.
|
|
--
|
|
-- Fresh mission runtime containers mint a new one-time pairing code
|
|
-- at startup. mission_runtime::ensure_container captures it from the
|
|
-- container's stdout and persists it here so the topology_worker's
|
|
-- ZeroClawDriveExecutor can lazy-pair with THIS gateway (instead of
|
|
-- reusing the shared runtime's env-derived ZEROCLAW_TOKEN, which the
|
|
-- fresh gateway doesn't accept).
|
|
--
|
|
-- Nullable: pre-C3-pair missions + non-mission topology runs fall
|
|
-- back to the shared-runtime env auth path.
|
|
|
|
ALTER TABLE missions ADD COLUMN runtime_pairing_code TEXT;
|