Fresh protocols/Cargo.lock resolves time 0.3.55 and fails devenv rustc 1.86 MSRV #10

New issue

Open

opened 2026-08-08 17:35:55 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-08-08 17:35:55 +01:00

Collaborator

A fresh protocols/Cargo.lock cannot build under the devenv toolchain (rustc 1.86.0): resolution picks time 0.3.55 / serde_with 3.21.0 / darling 0.23.0, whose rust-version is 1.88, and cargo refuses at build time. protocols/Cargo.lock is gitignored (.gitignore:4), so every checkout without a leftover lock resolves fresh and hits this; the workspaces use resolver = "2", which ignores rust-version during resolution.

Evidence, observed 2026-08-08 on a clean worktree (branch agent/nutxx-lookup-cdk-017, but the chain is identical on master):

  time-core@0.1.9 requires rustc 1.88.0
  time-macros@0.2.32 requires rustc 1.88.0
Either upgrade rustc or select compatible dependency versions with
`cargo update <name>@<current-ver> --precise <compatible-ver>`

Dependency chain: ehash → cdk-common → jsonwebtoken 9.3.1 → simple_asn1 0.6.4 → time ^0.3.47; every time ≥0.3.46 has rust-version = 1.88.0 (crates.io index), and simple_asn1 0.6.4's ^0.3.47 requirement excludes all 1.86-compatible releases. The chain exists on master too: cdk-common 0.16.0 (1572941d) has the same jsonwebtoken dependency, so this is not introduced by the CDK 0.17 bump.
The committed roles/Cargo.lock does not reproduce it: it holds simple_asn1 0.6.3 (time req ^0.3) with time 0.3.41, and incremental re-resolution preserves those pins. devenv up builds only the roles workspace, so the running stack is unaffected.
Workaround used in the worktree: cargo update simple_asn1@0.6.4 --precise 0.6.3, then cargo update time@0.3.55 --precise 0.3.41 (plus serde_with → 3.17.0, darling → 0.21.3), after which cargo check --manifest-path protocols/Cargo.toml --all-targets runs under 1.86.

A fresh `protocols/Cargo.lock` cannot build under the devenv toolchain (rustc 1.86.0): resolution picks `time` 0.3.55 / `serde_with` 3.21.0 / `darling` 0.23.0, whose `rust-version` is 1.88, and cargo refuses at build time. `protocols/Cargo.lock` is gitignored (`.gitignore:4`), so every checkout without a leftover lock resolves fresh and hits this; the workspaces use `resolver = "2"`, which ignores `rust-version` during resolution. Evidence, observed 2026-08-08 on a clean worktree (branch `agent/nutxx-lookup-cdk-017`, but the chain is identical on `master`): ``` time-core@0.1.9 requires rustc 1.88.0 time-macros@0.2.32 requires rustc 1.88.0 Either upgrade rustc or select compatible dependency versions with `cargo update <name>@<current-ver> --precise <compatible-ver>` ``` - Dependency chain: `ehash → cdk-common → jsonwebtoken 9.3.1 → simple_asn1 0.6.4 → time ^0.3.47`; every `time` ≥0.3.46 has `rust-version = 1.88.0` (crates.io index), and `simple_asn1` 0.6.4's `^0.3.47` requirement excludes all 1.86-compatible releases. The chain exists on `master` too: cdk-common 0.16.0 (`1572941d`) has the same `jsonwebtoken` dependency, so this is not introduced by the CDK 0.17 bump. - The committed `roles/Cargo.lock` does not reproduce it: it holds `simple_asn1` 0.6.3 (`time` req `^0.3`) with `time` 0.3.41, and incremental re-resolution preserves those pins. `devenv up` builds only the roles workspace, so the running stack is unaffected. - Workaround used in the worktree: `cargo update simple_asn1@0.6.4 --precise 0.6.3`, then `cargo update time@0.3.55 --precise 0.3.41` (plus `serde_with` → 3.17.0, `darling` → 0.21.3), after which `cargo check --manifest-path protocols/Cargo.toml --all-targets` runs under 1.86.

vnprc-agent added the

bug

label

2026-08-08 17:35:55 +01:00

vnprc-agent referenced this issue

2026-08-08 17:48:08 +01:00

bump CDK to 0.17.0 at vnprc/cdk 7011eebc (NUT-XX mint quote lookup) #8

vnprc-agent referenced this issue

2026-08-08 17:48:09 +01:00

bump CDK to 0.17.0 at vnprc/cdk 7011eebc (NUT-XX mint quote lookup) #8

vnprc-agent referenced this issue

2026-08-13 06:38:49 +01:00