Skip to content

r2g: seed declared dependencies into private file registry before artifact smoke #408

Open

Description

@ORESoftware

zed r2g currently fails before publish.smoke_test for packages with declared dependencies when using its default private file-registry mode.

Observed on exact-head package certification on 2026-09-15:

  • zed-pkg/zed-mcp-server.rs#19 head ccf281f5313c9246330fbd7c5c093a8b487e6ea3: zed validate passes, zed pack passes, then zed r2g fails with package ores-otel/ores-mcp-server-core-libs not found in file registry.
  • zed-pkg/zed-web-server.rs#76 head bf9865a6f92d386d4b7f8643017550a6a4cf84b2: zed validate passes, zed pack passes, then zed r2g fails with package zed-pkg/zed-interfaces not found in file registry.

This blocks the documented guarantee that r2g round-trips the emitted artifact into a mock consumer and executes publish.smoke_test for normal dependency-bearing packages.

Desired behavior

Before resolving/installing the candidate in the isolated file registry, seed or otherwise make available the exact declared dependency closure required by the candidate. The operation must remain deterministic/fail-closed and must not silently fall back to moving registry state.

Acceptable designs could include an explicit immutable dependency-seeding phase or a typed fixture/mirror input, but the default r2g path should not claim artifact smoke completion unless the candidate is actually installed with its declared dependencies and publish.smoke_test executes.

Acceptance

  • dependency-bearing package succeeds through zed pack -> isolated install -> publish.smoke_test;
  • missing/unresolvable dependency fails with a typed actionable error;
  • exact package/dependency identities are recorded in evidence;
  • tests cover same-org and cross-org dependencies;
  • no dependency is satisfied from ambient developer state;
  • preserve offline/private file-registry determinism where possible.

Activity

  1. ORESoftware commented on Oct 26, 2026

    @ORESoftware
    ContributorAuthor

    Reproduction from a second package family — 2026-10-26

    The existing isolated-registry gap is now reproduced on exact-head release certification for ores-rate-limit/ores-rl-lib-core PR #60, head 395931b49fcbd6f765a5a1d54abb26305e17309a, using pinned Zed CLI v0.3.1 at 388161f.

    Executed Release Zed run #40277694580 completed Rust/Redis tests, all three TLA+ model checks, descriptor validation, zed pack, and the independent archive consumer compile. It then failed specifically at zed r2g --clean with: package oresoftware/next-loggers not found in file registry.

    The candidate's resolver-produced .zpkg.lock pins oresoftware/next-loggers@0.1.0 and its ores-otel/ores-interfaces@0.1.0 dependency. The current r2g code snapshots a configured file registry only when ZED_PKG_REGISTRY is already file://; with the default HTTP registry it starts an empty private registry and cannot install the candidate's dependency closure. The candidate's publish.smoke_test is therefore NOT_RUN; this is a release-gate failure, not a successful round-trip.

    This strengthens the existing #408 acceptance case: seed the exact immutable lock dependency closure into the isolated registry (including transitive packages and digest verification), or use another explicitly disposable isolated registry. Fail closed with an actionable error for missing/unresolvable closure; do not silently use ambient local packages, switch a production version to persistent server mode, or weaken the release gate. The issue remains the single root tracker; no duplicate issue/PR was opened.

  2. ORESoftware commented on Oct 26, 2026

    @ORESoftware
    ContributorAuthor

    Implementation boundary — 2026-10-26

    The current-main history confirms the older #23 change already snapshots a configured file:// registry into the isolated workspace. That implementation deliberately returns without seeding when the configured registry is HTTP(S), so replaying or re-merging #23 does not fix this issue.

    Fresh exact-head evidence: ores-rate-limit core #60 at 395931b49fcbd6f765a5a1d54abb26305e17309a has a stepful release run #40277694580. The pinned CLI and descriptor validation passed; the local round-trip step then failed with package oresoftware/next-loggers not found in file registry. The installed-artifact publish.smoke_test was not reached. Producer #60 has no submitted review; no merge or publication is admissible.

    Recommended root fix for a follow-up PR:

    1. In isolated HTTP(S) mode, require a valid resolver-produced .zpkg.lock whenever direct or build dependencies exist; fail closed if it is absent or doesn't cover the declared requirements.
    2. Seed the private file registry from that lock's exact transitive package set only. For every entry, verify package identity, exact version, format, VCS tag/commit, byte count, and SHA-256 against the lock before writing local metadata.
    3. Expose only each locked version in the private registry index; don't fall back to ambient local registrations or mutable server state. Preserve the configured-file-registry snapshot path and keep persistent server mode opt-in.
    4. Add same-org, cross-org, transitive-closure, missing-lock, missing-package, yanked-version, and digest-mismatch negative tests. The test must prove the smoke command actually ran against the installed artifact.

    Downstream ores-middleware #303 also has an executed Zed consumer failure because the rate-limit package is not yet published and lock-pinned; treat that as a dependency/promotion blocker, not as evidence to patch around the package gate.

  3. ORESoftware commented on Oct 26, 2026

    @ORESoftware
    ContributorAuthor

    Additional fail-closed case — 2026-10-26

    Rechecked current main at 388161f681bac8ae704a22a593280ceed4cc4fa9 (src/r2g.rs, blob b9650df6caca532dff8d9b95cf6f16ad072dfce6). snapshot_configured_file_registry currently returns Ok(()) when the configured file:// path does not exist (around lines 381–383). That makes a misspelled or unavailable local registry look like a successful no-op until a later package-resolution error, rather than a typed, actionable configuration failure.

    Please add a negative test for a missing file:// registry and fail closed with a typed error that names the registry configuration (without exposing secrets). Keep the intentional HTTP(S) branch separate: isolated mode still needs explicit, immutable dependency-closure seeding for remote registries, and must not claim the smoke test ran unless the candidate and locked dependencies install and publish.smoke_test executes. The existing non-file-registry no-op test should continue to cover the HTTP(S) branch, not stand in for the missing-path case.

  4. ORESoftware commented on Oct 26, 2026

    @ORESoftware
    ContributorAuthor

    Consolidated controller receipt — 2026-10-26

    Focused follow-up: PR #541, head b6d475afd6b312de1be07a581562ec5bf162c8a0, base main 388161f681bac8ae704a22a593280ceed6cc4fa9. The change adds a negative test and makes a missing configured file:// registry fail closed. It deliberately does not claim to solve HTTP(S) dependency-closure seeding; #408 remains open.

    Exact-head evidence (PR #541):

    • PASS: agents policy run 40320810611, ores-lint run 40320810139, and Formal review procedure run 40320810103 completed successfully.
    • FAIL (executed): fp-conformance 40320809964 reports broad repository-wide budget regressions; the touched src/r2g.rs is not named in its findings. CLI portability 40320810778 fails formatting in existing graph_export files. ci, OCI, and consumer-smoke workflows also fail during existing cargo build --locked / formatting gates before the focused regression can be certified.
    • AUDIT_ONLY-BLOCKED / NOT_RUN: Zed latest dependency gate 40320809966 stops at the required private-source read credential; its build and dependency-resolution steps are skipped. No credential was added or copied.
    • Not merge-admissible: PR remains draft, no independent review, and several exact-head workflows fail. These outcomes are not green evidence.

    Next gates: keep the focused PR draft; resolve the repo-wide format/locked-build baseline through its proper owners without mass-bumping unrelated dependencies; supply the approved read-only private-source capability through repository settings; rerun exact-head Rust tests. The larger #408 fix still needs immutable direct/transitive lock-closure seeding for isolated HTTP(S) mode, digest/identity verification, and proof that the installed-artifact publish.smoke_test actually executes.

  5. ORESoftware commented on Oct 27, 2026

    @ORESoftware
    ContributorAuthor

    Zed CLI registry recovery receipt — 2026-10-26

    PR #541 is open/draft at exact head b6d475afd6b312de1be07a581562ec5bf162c8a0, based on current main 388161f681bac8ae704a22a593280ceed6cc4fa9; no reviews. Do not promote it yet.

    • CI run 40320809902: FAIL on the exact head. The job executed; Docker CLI image build and current CLI build failed, with downstream install/OCI smoke steps skipped. This is not a zero-step run.
    • Zed latest dependency gate 40320809966: FAIL on the exact head at the required private-source read-credential check; candidate build/dependency replay were skipped. Do not rotate or expose credentials; restore only the already-authorized read path if available.
    • Pinned fixture candidate smoke 40320811221: candidate authority derivation and contract validation passed, but candidate build and representative fixture smoke failed; another matrix case was skipped.

    Next gates: inspect and fix the actual CLI build failures, resolve the authorized private-source read boundary without secret leakage, then rerun exact-head Rust/Node/Docker/install tests and package-provenance canaries. No mass package bumps and no merge while checks fail.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions