mirror of
https://github.com/freemkv/freemkv-keysources.git
synced 2026-10-07 18:13:11 +00:00
Matthew Jackson
f61a3c3372
The three crates move together because they must: freemkv resolves its siblings from their git TAGS in its own CI, where keysources still wanted ureq 2, so cargo saw no conflict and the earlier split bump went green on a dependency graph the release never uses. The qa and hash-matrix workflows resolve those siblings from their dev PATHS, cargo unifies to a single ureq, and the mismatch stops compiling. Verified here the way those workflows see it: freemkv built against the sibling paths now resolves one ureq 3.4.0 and no ureq 2 anywhere. Notable API changes: AgentBuilder::new()..build() -> Config::builder()..build() + Agent .redirects(0) -> .max_redirects(0) .timeout_read(d) -> .timeout_recv_response(Some(d)) .resolver(closure) -> the Resolver trait .set(k, v) -> .header(k, v) ureq::Response -> http::Response<ureq::Body> Error::Status(code, _) -> Error::StatusCode(code) Error::Transport(_) -> fans out; matched with a catch-all Two hazards the new resolver API introduces, both handled: Agent::new_with_config compiles fine and then silently ignores a custom resolver, so the pinned addresses would be dropped and every request would go back to live DNS -- reopening the DNS-rebinding window the guards exist to close, with no symptom. Only Agent::with_parts takes a resolver, and that is what every pinned agent here uses. ResolvedSocketAddrs is a fixed 16-slot array whose push writes straight into it, so a host publishing more than 16 addresses would panic the calling thread. Truncated to the first 16. The four reply stubs used ureq::Response::new, which v3 removes; they are rebuilt with http::Response::builder over a ureq::Body, so they stay server-free unit tests.