Summary

Dependabot keeps opening the same PR to bump self_update from 0.42.0 to 0.44.0 (#711, #724, and now #757). Each one has been merged or will merge as a no-op: only Cargo.lock is updated, never the Cargo.toml requirement, so the change is silently reverted by the next build/resolve and Dependabot re-proposes it on the following run.

Mechanism

1. Cargo.toml pins self_update = "0.42" (i.e. ^0.42 → >=0.42.0, <0.43.0).
2. Dependabot bumps only Cargo.lock to 0.44.0, leaving the ^0.42 requirement in place. The lockfile now contradicts the manifest.
3. CI runs plain cargo build/cargo test (no --locked), so cargo silently re-resolves self_update back to 0.42 and rewrites the lock:

   Downgrading self_update v0.44.0 -> v0.42.0 (available: v0.44.0)
   

   CI is green — on 0.42.
4. The reverted lock means the installed version stays 0.42. Next Dependabot run sees "still 0.42, 0.44 available" and files the bump again. Loop.

Evidence (version churn in main)

The reverts come from whatever next re-resolves the lock: the scheduled sync-cargo-lock.yml job (#714), or an unrelated Dependabot bump that regenerates the lock as a side effect (#751).