fix: migrate ureq 2.x call sites to the resolved 3.x API - #36
Merged
Conversation
`cargo` refuses to parse the lockfile on `origin/main`: error: failed to parse lock file at: Cargo.lock Caused by: package `crossterm` is specified twice in the lockfile It contained THREE `crossterm` entries — 0.28.1, 0.29.0 and 0.29.0. Two identical versions is malformed; a package may appear more than once only at distinct versions. Introduced by 56dc58d ("chore(deps): bump crossterm from 0.28.1 to 0.29.0", #4). Regenerated with `cargo generate-lockfile`. The resolution is now 0.28.1 (direct, per `Cargo.toml`'s `crossterm = "0.28"`) plus 0.29.0 transitively — two distinct versions, which is valid. `cargo metadata` now exits 0 where it previously exited 101. Found while adding container packaging: the build failed before compilation even began, and reproduces identically with the host's own cargo 1.97.1 outside any container. ⚠ THIS DOES NOT MAKE THE CRATE BUILD. A separate, pre-existing breakage remains — the source does not compile against the resolved `ureq`: error[E0599]: no method named `set` found for struct `RequestBuilder<B>` --> src/main.rs:66:10 error[E0599]: no variant named `Status` found for enum `ureq::Error` --> src/main.rs:70:26 Both are ureq 2.x APIs removed in 3.x, so a dependency bump landed without the corresponding source migration. That is left for a separate change rather than bundled into a lockfile repair. Taken together these mean coord-tui's CI has not been compiling this crate: two dependency bumps merged, one breaking the source and one corrupting the lockfile, with nothing red enough to stop them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cargo.toml already requests ureq = "3" and the lockfile resolves ureq 3.3.0, so the crate hasn't compiled since that dependency was bumped — the source still used 2.x-only methods: - `.set(k, v)` -> `.header(k, v)` - `.send_string(&s)` -> `.send(&s)` - `ureq::Error::Status(_, resp)` no longer exists; 3.x's default `Error::StatusCode(u16)` carries no response body at all. Disabled `http_status_as_error` on the request so 4xx/5xx responses still arrive as `Ok`, preserving the original fallback behaviour of reading the JSON body of error responses instead of discarding it. - reading the body moved from `Response::into_string()` to `Response<Body>::body_mut().read_to_string()`. Verified against the actual ureq-3.3.0 crate source under ~/.cargo/registry rather than from memory. Two unrelated Dependabot bumps landed back to back on this repo: one broke this source (ureq 2->3), the other corrupted Cargo.lock (fixed separately in #35, which this branch is stacked on). Neither was caught because CI was not actually compiling the crate — this is the motivating case for adding a real `cargo build`/`cargo test` gate rather than relying on green Dependabot PRs. cargo build --release: exit 0 cargo test: exit 0 (0 tests present) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
hyperpolymath
marked this pull request as ready for review
July 27, 2026 18:33
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacks on #35 — merge after it
This branches from
fix/corrupt-cargo-lock(#35), notmain. It must merge after #35, since it needs that branch's repairedCargo.lockto build at all.What's broken
src/main.rsusedureq2.x-only APIs, butCargo.tomlalready requiresureq = "3"and the lockfile resolvesureq 3.3.0. That mismatch means the crate has not compiled since theureqbump landed:Fix
Migrated the single HTTP call site to the ureq 3.3.0 API (verified against the actual crate source under
~/.cargo/registry, not from memory):.set(k, v)->.header(k, v).send_string(&s)->.send(&s)ureq::Error::Status(_, resp)is gone. ureq 3.x's defaultError::StatusCode(u16)carries no response body, so the request now setshttp_status_as_error(false)to keep 4xx/5xx responses arriving asOk, preserving the original behaviour of still reading the JSON body of error responses instead of discarding it.Response::into_string()toResponse<Body>::body_mut().read_to_string().Went with migrating the code (not pinning
Cargo.tomlback to 2.x) becauseCargo.tomlalready declares intent forureq = "3"— the source was just never updated to match.Why this matters for CI
Two separate Dependabot bumps landed back to back on this repo: one broke this source (
ureq2->3 API), the other corruptedCargo.lock(crossterm listed twice, fixed in #35). Neither was caught because nothing in CI was actually runningcargo buildon this crate — both merged green. Worth adding a real build gate off the back of this.Verification
cargo build --release: exit 0cargo test: exit 0 (no tests present in the crate yet)Cargo.lockuntouched beyond fix(deps): repair the corrupt Cargo.lock (crossterm specified twice) #35's fix; no unrelated formatting/flake.nix/Containerfile changes.