build(docker): stop copying the gitignored Cargo.lock

[AdaWorldAPI]

Summary

Fixes the Railway build failure. Both Dockerfiles ran COPY Cargo.toml Cargo.lock ./, but Cargo.lock is gitignored — so it is not in the build context and the COPY fails outright:

COPY Cargo.toml Cargo.lock ./
Build Failed: failed to compute cache key: failed to calculate checksum of ref
  …: "/Cargo.lock": not found

One line changed in each file, plus a comment explaining why the omission is deliberate so it is not "helpfully" restored later.

Three things this is not

• Not a redeploy. COPY fails when a source is missing from the context; re-running the same build produces the same failure.
• Not a checksum to disable. "failed to compute cache key / failed to calculate checksum" is BuildKit's phrasing for source not found, not a corrupt or mismatched file. There is no flag to skip it.
• Not a job for a dummy Cargo.lock. Committing an empty one would contradict the .gitignore rationale ("this is a library crate consumed by sibling repos via git dependency, so a committed lock is never used by a downstream build and only goes stale against the branch") and would plant a second, fake source of truth for resolution — the exact thing that policy exists to prevent. Cargo resolving fresh in the image is the intended behaviour.

Verification

No Docker daemon in this sandbox, so I reproduced the build context instead: exported the committed tree with git archive HEAD (what Railway actually sees) and replicated the Dockerfile's exact COPY set into a clean directory.

check	result
Cargo.lock in the committed tree	absent — confirms the reported cause rather than assuming it
old line simulated against that tree	Cargo.toml OK, Cargo.lock MISSING — reproduces the failure
cargo metadata on the reproduced context	exit 0, lock generated by resolve
RUSTFLAGS="-C target-cpu=x86-64-v3" cargo build --release (the image's first RUN, same flags)	Finished release profile in 36.14s

The cargo metadata step matters beyond resolution: manifest load is where the [patch.crates-io] chacha20 = { path = "vendor/chacha20" } entry and the declared [[example]]/[[bench]] targets are validated — the two hazards the existing Dockerfile comments warn about. Both pass with the reduced COPY set, so nothing else was silently depending on the lock.

Dockerfile.avx512 carries the identical line and the identical fix; it differs from Dockerfile only in target-cpu=x86-64-v4, which I did not build here (this sandbox is not AVX-512-pinned hardware and the image is documented as SIGILL-on-older-CPUs).

🤖 Generated with Claude Code

https://claude.ai/code/session_012wrzeZAdwGYTCKoxamwQht

---

Generated by Claude Code

Summary by CodeRabbit

• Chores
  • Updated the Rust toolchain used in standard and AVX-512 Docker builds to version 1.98.1.
  • Docker builds now resolve dependencies from the project manifest without requiring a lockfile.
  • Simplified runtime build verification output.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Essentials

Run ID: b5a21cf9-1a06-47c2-b2bc-3d491736113d

📥 Commits

Reviewing files that changed from the base of the PR and between 112be27 and d23bcdd.

📒 Files selected for processing (2)

• Dockerfile
• Dockerfile.avx512

---

📝 Walkthrough

Walkthrough

Both Dockerfiles upgrade Rust to 1.98.1, copy only Cargo.toml during builds, and simplify runtime verification messages.

Changes

Docker build updates

Layer / File(s)	Summary
Rust toolchain and build context Dockerfile, Dockerfile.avx512	Both builds pin Rust 1.98.1 and omit Cargo.lock from the copied manifests. Verification output no longer includes the Rust version. The AVX-512 build retains target confirmation.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Suggested reviewers: claude

Poem

A rabbit reads each line,
The patch grows clear beneath the moon,
Small changes hop in place,
Tests guard the garden path,
Reviews bloom before the dawn.

---

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_033401ee-1523-44be-8233-14f85429c36d)

[AdaWorldAPI]

Pushed d23bcdd0 — a second Railway blocker, found while verifying the first, that would have failed the build one line later.

The toolchain pin was stale

Both images installed 1.97.1, and Dockerfile asserted in prose that this "MUST match rust-toolchain.toml (channel = 1.97.1)". That is no longer true:

source	value
rust-toolchain.toml	channel = "1.98.1"
Cargo.toml	rust-version = "1.98"
both Dockerfiles	1.97.1

The bump log records 1.97.1 → 1.98.1 on 2026-09-01; the Dockerfiles were missed. Observed, not inferred — 1.97.1 was already installed here, so I ran it against the reproduced build context:

$ cargo +1.97.1 build --release
error: rustc 1.97.1 is not supported by the following package:
  ndarray@0.17.2 requires rustc 1.98

Cargo refuses at manifest load, so fixing only the COPY would have handed the next deploy a fresh failure. Both are the same reported defect — "ndarray fails in railway" — so they land together rather than as a second PR fixing the next line of the same build.

The comment was the mechanism, so it changed too

rust-toolchain.toml warns: "A stale comment on a version pin is how the next reader learns the wrong number." This Dockerfile was that failure — its prose didn't just go stale, it asserted the wrong requirement, which is why the mismatch survived the bump. The prose now carries rationale only; the version appears solely where it is mechanical (the rustup argument and its grep -q assertion), and the CMD echo no longer restates it.

Verification — all three RUN steps, on 1.98.1

Against the reproduced context (git archive HEAD + the Dockerfile's exact COPY set), with the image's own RUSTFLAGS="-C target-cpu=x86-64-v3":

Dockerfile step	result
cargo build --release	OK
cargo build --release --features jit-native	Finished release profile in 52.10s
cargo test --release --lib -- hpc::	1762 passed, 0 failed, 30 ignored (exit 0)

Unchanged from the PR body: no Docker daemon here, so the image itself is not built, and Dockerfile.avx512 is not exercised (this sandbox is not AVX-512-pinned hardware; that image is documented as SIGILL-on-older-CPUs). Its two changed lines are identical to Dockerfile's.

Worth flagging for the merge decision: no CI job in this repo builds either Dockerfile, so a green matrix here does not cover this change — the evidence above is what stands behind it.

---

Generated by Claude Code