Committed C-FFI lockfile prevents locked builds

[Kewe63]

Summary

The standalone C-FFI workspace has a committed Cargo.lock that no longer matches the root crate's rgb-lib dependency. Both locked metadata resolution and the exact locked build stop before compilation.

Affected revision

• Branch: dev
• Commit: af03c7f1a65135a429f05a5820600338215954dc
• C-FFI package: rln-c-ffi 0.1.0
• Rust: 1.94.0

Reproduction

cargo +1.94.0 metadata --locked \
  --manifest-path bindings/c-ffi/Cargo.toml \
  --format-version 1

cargo +1.94.0 build --locked \
  --manifest-path bindings/c-ffi/Cargo.toml

Actual result

Both commands exit with status 101:

Updating git repository `https://github.com/UTEXO-Protocol/rgb-lib.git`
error: cannot update the lock file .../bindings/c-ffi/Cargo.lock because --locked was passed to prevent this

Expected result

The committed lockfile should resolve the standalone C-FFI workspace without modification, allowing its documented reproducible --locked build to start.

Root cause

bindings/c-ffi/Cargo.toml depends on the root crate by path and states that its committed lockfile tracks the parent's dependency pins. The current root Cargo.toml pins rgb-lib to UTEXO tag v0.3.0-beta.34, while bindings/c-ffi/Cargo.lock still records:

rgb-lib 0.3.0-beta.7
https://github.com/dcorral/rgb-lib.git?rev=94b6221e...

Cargo therefore needs to rewrite the nested lockfile before it can resolve the workspace, which --locked correctly forbids.

Relevant source

• Parent rgb-lib pin:

  rgb-lightning-node/Cargo.toml

  Line 98 in af03c7f

  rgb-lib = { git = "https://github.com/UTEXO-Protocol/rgb-lib.git", tag = "v0.3.0-beta.34", default-features = false }

• C-FFI standalone workspace contract:

  rgb-lightning-node/bindings/c-ffi/Cargo.toml

  Lines 34 to 41 in af03c7f

  	# Own workspace so the parent crate's rust-lightning path-submodule workspace
  	# isn't pulled in. The committed Cargo.lock locks `rgb-lib` to the same
  	# revision the parent uses.
  	[workspace]
  	# Mirror the parent's [patch.crates-io] so we don't end up with two copies of
  	# `lightning` (which fails with trait-bound errors). Keep in lock-step with
  	# the parent's pins.

• Stale lock entry:

  rgb-lightning-node/bindings/c-ffi/Cargo.lock

  Lines 4762 to 4765 in af03c7f

  	[[package]]
  	name = "rgb-lib"
  	version = "0.3.0-beta.7"
  	source = "git+https://github.com/dcorral/rgb-lib.git?rev=94b6221ea9bf04562d89c21c9f074f4ecfbddd5d#94b6221ea9bf04562d89c21c9f074f4ecfbddd5d"

Impact

Clean or CI builds that enforce the committed C-FFI lockfile cannot resolve dependencies. This finding is limited to the standalone C-FFI locked-build boundary; no C-FFI runtime behavior was exercised.

Duplicate-check evidence

Open and closed issues and PRs in both UTEXO and upstream were searched for c-ffi Cargo.lock, locked build, the Cargo error text, and the affected manifest path. Current open PR file overlaps and their comments/reviews were inspected.

Draft PRs #139 and #140 regenerate the nested lockfile for a separate, blocked funding-recovery dependency stack pinned to a contributor rgb-lib revision. Draft PR #128 similarly carries a lock update for its own contract-import dependency pin. None targets or validates the current dev tag, and none discusses this locked-build failure. No duplicate or current-dev fix was found. Private maintainer discussions are not visible.

Suggested fix direction

Regenerate bindings/c-ffi/Cargo.lock from the current dev manifests, verify both commands above with --locked, and add a lightweight locked C-FFI metadata/build gate whenever parent dependency pins change.