envoyproxy / envoyproxy/bazel-registry

wasmtime: restore upstream Cargo.lock in its entirety — stop pruning, use source-pinned versions

Open
#38 0 comments 1 reaction 2 assignees Claimed by @phlax View on GitHub
Dominant language
Starlark
Stars
0
Forks
8
Avg merge
3h 22m
Merged PRs (30d)
52

Description

## Background

The `wasmtime@45.0.2.envoy` module carries a ~6800-line patch (`modules/wasmtime/45.0.2.envoy/patches/wasmtime.patch`) that rewrites upstream wasmtime's `Cargo.lock`, pruning it down to the c-api subset. This has caused a chain of failures in the envoy bzlmod migration:

1. The pruning deleted the `[[package]] cc` entry (upstream pin `1.2.41`) while `cc` remained a required dependency. cargo therefore **re-resolved `cc` against live crates.io at fetch time** during crate_universe splicing. When crates.io published `cc 1.4.4`, the generated repo name changed (`cu__cc-1.4.3` → `cu__cc-1.4.4`), breaking `proxy-wasm-cpp-host`'s hardcoded `use_repo` list with:
```
ERROR: module extension ...%crate does not generate repository "cu__cc-1.4.3", yet it is imported ... (did you mean 'cu__cc-1.4.4'?)
```
2. A subsequent repin attempt (current state on the `wasmtime` dev branch, phlax/bazel-registry@5a6c6f3) fixed `cc` but bumped **many** registry crates away from upstream's pins (`syn`, `clap`, `thiserror`, `adler2`, etc. — some to versions of dubious existence, e.g. `shlex 2.0.1`, `syn 3.0.4`), and in the process lost the `wasmtime-internal-c-api-macros` workspace-member entry, breaking analysis:
```
ERROR: no such target '@@rules_rust++crate+cu//:wasmtime-internal-c-api-macros' ... referenced by '@@wasmtime+//:rust_c_api'
```

The root problem: **hand-maintaining a pruned lockfile is not sustainable**, and any gap in it silently falls back to live crates.io resolution — a time bomb.

## Required change

Stop pruning. Use upstream's `Cargo.lock` **in its entirety, byte-for-byte**, with all versions exactly as pinned at source (wasmtime v45.0.2 tag):

1. **Remove the entire Cargo.lock hunk from `wasmtime.patch`.** If the patch contains any genuinely-needed non-lock edits (e.g. `Cargo.toml` manifest changes), keep only those; if the lock hunk was the whole patch, drop the patch file entirely and remove its entry from `source.json`.
2. If manifest patches mean the pristine upstream lock is inconsistent with the patched manifests (which would trigger re-resolution), instead vendor the *complete* upstream `Cargo.lock` as an **overlay file** with only the *minimal* mechanical adjustments required for consistency with the patched manifests — versions must remain exactly upstream's pins; no crates.io re-resolution output may be committed.
3. Verify crate_universe splicing works against the full lock: `@cu//:anyhow`, `@cu//:log`, `@cu//:once_cell`, `@cu//:tracing`, `@cu//:wasmtime`, and `@cu//:wasmtime-internal-c-api-macros` (all referenced by `modules/wasmtime/45.0.2.envoy/overlay/BUILD.bazel`) must resolve. Watch for workspace members with problematic build scripts being dragged into the resolution; if any are, handle via crate annotations rather than lock pruning.
4. **Update `modules/proxy-wasm-cpp-host/0.0.0-260704-f2db56a.envoy/MODULE.bazel`** `use_repo` list to match the upstream-pinned resolution (e.g. `cu__cc-1.2.41`, not `1.4.3`/`1.4.4`; regenerate the full list with `bazel mod tidy` or equivalent). Workspace-member repos (`cu__wasmtime-*`, `cu__cranelift-*`, `cu__pulley-*`) remain commented out as currently.
5. Update integrity hashes in `modules/wasmtime/45.0.2.envoy/source.json` (patch and/or overlay entries, SRI sha256).
6. Acceptance: with this change, the crate resolution must be fully deterministic — independent of when it runs, the state of crates.io, and the rules_rust version selected by MVS. `wasmtime-internal-c-api-macros` and all `@cu//:` targets used by the overlay must resolve, and an envoy bzlmod build consuming these modules must pass analysis.

## Notes

- Dev branch with current (broken) repin state: `wasmtime` branch of phlax/bazel-registry (HEAD 5a6c6f3202a097272e84780a811a3127ec1af70a) — useful as reference for what NOT to do.
- The pruning pattern is homegrown (introduced in #4889 / commit 3d3c8f5); it is not BCR practice and no upstream maintains such a patch. The overlay BUILD.bazel shape (Google-licensed) is fine and stays.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.