Dependabot runs for `cargo` dependencies time out

[EliahKagan]

Current behavior 😯

We didn't get a Dependabot PR to upgrade cargo dependencies today, though we should have, because when Dependabot runs on this repository for that ecosystem, it times out. This can be seen in recent runs shown at:

https://github.com/GitoxideLabs/gitoxide/network/updates/9454592/jobs

For convenience, a couple of those recent timed-out runs are:

• https://github.com/GitoxideLabs/gitoxide/actions/runs/22539861905/job/65293355364
• https://github.com/GitoxideLabs/gitoxide/actions/runs/22547712209/job/65312693131

I've rerun it a few times, and I plan to keep rerunning it throughout the day, but so far it has consistently timed out. I don't know of any reason it's taking too long, besides that this workspace has a lot of complex dependencies whose transitive dependencies are hard to resolve.

There are some benefits of using Dependabot, so I hope to fix this somehow. The cooldown feature seems to work pretty reliably in this repository, including even for transitive dependencies, and it doesn't have corresponding direct functionality in cargo.

I think the usual strategy for overcoming persistent Dependabot problems is to switch to Renovatebot. That's an excellent alternative in general, but while it has a feature that corresponds to cooldown, I don't think that feature works nearly as thorougly with cargo, since I think it is built to rely on integration with corresponding features in programs like cargo, at least for the management of transitive dependencies.

My understanding is that it is specifically because Dependabot does so much stuff separate from running cargo that it is both able to have a more effective cooldown feature for our needs and able to take massive amounts of time to do its work even when a more closely cargo-based implementation would operate faster.

Expected behavior 🤔

It's fine if it takes a long time, but it should be complete.

Though not ideal, it would also be sort of okay if it often timed out, but if rerunning it was a reliable way to get it to work. However, this would soon stop being okay, if we end up getting more dependencies over time as more gix-* crates are implemented.

Git behavior

Not applicable. Git does have some Rust code now, but I don't think it has lots of complex dependencies as here, so no analogous problem is even in principle applicable, if I understand correctly.

Steps to reproduce 🕹

See above.

I've also reproduced this in my fork. I was aware of it a couple weeks ago, but I hoped it either would go away or that the runs would somehow work better in this upstream repository. In the past, I have sometimes had timeouts in my fork even when Dependabot works here. But it's not working here now.

[Byron]

Without having read anything, here is what Codex 5.3 (thinking, high) says:

---

I dug through the full logs (not just the tail) for these runs:

• https://github.com/GitoxideLabs/gitoxide/actions/runs/22539861905/job/65293355364
• https://github.com/GitoxideLabs/gitoxide/actions/runs/22547712209/job/65312693131
• https://github.com/GitoxideLabs/gitoxide/actions/runs/22549153529/job/65316235723 (additional rerun on 2026-03-01)

and compared them to a recent successful full cargo run:

• https://github.com/GitoxideLabs/gitoxide/actions/runs/21559957395 (2026-02-01)

Findings:

1. There is no internal exception/stacktrace in the failing runs.
   The only terminal error is:
   ##[error]The operation was canceled.

2. Cancellation is highly deterministic at ~55 minutes in all three March 1 reruns:

   • 3298s
   • 3299s
   • 3298s

3. The updater is actively progressing until cancellation (it is not “stuck” on one crate).
   Each timed-out run processes ~470+ dependencies (Checking if ... needs updating) before being cut off.

4. No obvious upstream network failure pattern:

   • no 429/5xx from crates.io or index.crates.io
   • mostly cached 304 responses from the index

5. This looks like a performance regression vs 2026-02-01:

   • 2026-02-01 successful run finished in ~46.1 minutes
   • 2026-03-01 reruns all hit cancellation at ~55.0 minutes

6. The Dependabot updater image changed between those dates:

   • success run pulled ghcr.io/dependabot/dependabot-updater-cargo:e9f10d...
   • timed-out runs pulled ghcr.io/dependabot/dependabot-updater-cargo:4b7e287...

So at this point this looks less like a repo config bug and more like either:

• an external timeout cap + slower updater behavior, or
• a Dependabot updater regression for cargo workloads of this shape.

[EliahKagan]

Thanks. One possible thing to look into, in older successful logs (if still available), is whether there were fewer dependencies then. That is, I assume we have a bigger and more complex dependency situation now, but maybe that's actually not the reason for the timeouts.