Skip to content

bregctl dev: Docker resolution, token minting order, stop without a session, PATH hits and startup refusal causes #874

Description

@jeremi

All in crates/registry-bregctl/src/dev/mod.rs unless named.

  1. database and stop_database take the supervisor's resolved --docker-bin, while package resolves docker from PATH for the rehearsal database and dev stop resolves from PATH with no flag. Thread the resolved path into package and give dev stop the flag; pin with the live lifecycle test run with --docker-bin set and a PATH without Docker.
  2. Client tokens are minted once Mint is ready and before the rehearsal, activation, verification, BReg start and readiness, with lifetimeSeconds: 300 (dev/config.rs) and maxTokenLifetimeSeconds: 300. The 120 s child deadlines and the 45 s readiness deadline sum past 300 s in the worst case, so a very slow first start reaches seed with expired tokens. The live lifecycle takes 25 to 40 s and every dev start re-mints, so the window is wide in practice. Mint after BReg readiness, immediately before seed; pin by the token files' modification times following the package and activation records.
  3. dev stop in a directory where dev start never ran reports status: stopped; it should say that no session exists.
  4. executable() keeps a non-canonical PATH hit and records no version in the state document, so a later doctor cannot tell which binary served the session.
  5. The connection URL in dev/config.rs uses localhost while the container publishes on 127.0.0.1:<port>; a host that resolves localhost to ::1 first fails to connect. Use the literal the container publishes.
  6. When the runtime refuses the package, StartupError::PackageRefused (crates/registry-breg/src/startup.rs) discards the underlying cause through map_err, so the supervisor's diagnosis cannot name it. Keep the cause. Found through stale installed binaries: a breg and mint on PATH that predate the current package format refuse the package the current bregctl builds, and the live test passes only because worktree-built binaries precede them. Worth checking whether CI can reach the same state.

Origin: review of PR #865 (items 1 and 2 raised by Codex, answered in-thread).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions