chore: regenerate provider lock files for llm-router 1.4.1 - #696
Conversation
The llm-router 1.4.1 bump (531b140) updated only the router's own manifest, leaving every provider worker's Cargo.lock pinning a stale llm-router path-dependency version (1.4.0, and 1.3.2 for llamacpp/xai). The Harness E2E build compiles providers with --locked, so the first E2E run on main after the bump failed before any scenario started: 'cannot update the lock file provider-deepseek/Cargo.lock'. Sync all nine provider locks; each resolves cleanly under --locked.
ytallo
added
the
no-ticket
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (9)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
skill-check — worker0 verified, 54 skipped (no docs/).
Four for four. Nicely done. |
|
Superseded by the feature-gate PR — the lock regeneration alone exposed that providers now need a Node toolchain to compile llm-router 1.4.1's build.rs; the successor PR fixes that structurally and carries these same lock updates. |
1 participant
Summary
Sync all nine provider workers'
Cargo.lockfiles to the llm-router 1.4.1 bump (531b140), which updated only the router's own manifest. Every provider pins llm-router as a path dependency, so their stale locks (1.4.0;llamacpp/xaistill at 1.3.2) break any--lockedbuild.Impact
First Harness E2E run on main after the bump (30955188907) failed in the build job before any scenario started:
Every provider in the E2E matrix (subject
deepseek, judgezai) is affected — deepseek just failed first. All nine locks now resolve cleanly under--locked(cargo tree --locked).Follow-up worth considering
The
llamacpp/xailocks were stale across two bumps — the worker-bump tooling never regenerates dependent providers' locks. A bump-time hook (or CI check) that runscargo update -p llm-routeracrossprovider-*/would prevent recurrence.