pip index was slow and the agent's resolve timed out at 300s; it logged the package as "unresolvable" instead of...

TL;DR: Retry the resolve with a longer timeout and learn to tell a slow index from a real conflict. A 300-second timeout means the index was slow, not that the packages are unresolvable: raise the timeout, retry, and only log "unresolvable" when the resolver actually reports a conflict. Keep timeout and conflict as two separate statuses.

the agent's resolve timed out at 300s; it logged the package as "unresolvable" instead of retrying

1. Re-run the resolve with a longer timeout.

Expected: slow indexes finish instead of tripping the deadline, and the resolve completes.

1. Retry once more before concluding anything, and time the attempt.

Expected: separates one slow run from a consistently slow index.

1. Check whether the index is responding normally with a simple package metadata fetch.

Expected: confirms index slowness versus a local problem.

1. If the resolver reports an actual conflict, log the conflicting constraints; if it only ever times out, log "index timeout", never "unresolvable".

Expected: humans see the true cause and chase the right fix.

Use this when

• pip's resolve timed out (e.g. at 300s) and the agent logged "unresolvable"
• The package index was slow during a resolve
• A timeout got misreported as a dependency conflict
• Operators are chasing constraint conflicts that do not exist

Not for this skill when

• pip raises ResolutionImpossible with a genuine conflict (different diagnosis path)
• The index is down entirely (outage handling, not timeout tuning)
• The timeout happens during download rather than during resolution

Variant phrasings

• pip resolve timeout logged as unresolvable
• pip index slow, resolve timed out
• 300s timeout marked unresolvable
• pip resolver timeout versus real conflict

Why it happens

The agent mapped every resolver exception to "unresolvable". Timeouts and conflicts are different failures with different fixes, and conflating them sends humans chasing dependency constraints when the real problem was a slow index. The status string lied about the failure mode.

Edge cases

• Some indexes are consistently slow at peak hours; schedule heavy resolves off-peak instead of fighting the clock.
• A longer timeout on every run wastes agent time, so retry with backoff and cap the attempts.
• If the index is timing out for everyone, pause the upgrade queue instead of failing each item one by one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sGYYxSJirHu8ch7FRZ1j2g