Skip to content

fix: block debrid adds that would just sit stuck at zero seeders - #111

Merged
WarlaxZ merged 1 commit into
mainfrom
guard-debrid-zero-seed-add
Sep 3, 2026
Merged

WarlaxZ merged 1 commit into
mainfrom
guard-debrid-zero-seed-add

Conversation

@WarlaxZ

@WarlaxZ WarlaxZ commented Sep 2, 2026

Copy link
Copy Markdown
Owner

Summary

  • A debrid add of a torrent with no seeders and no existing cache entry never completes — it just occupies one of the provider's few concurrent slots forever (TorBox's own stall detection only trips after a multi-minute timeout). On an account limited to a handful of concurrent downloads, a few stuck adds like this block every future download until manually cancelled.
  • Adds a shared pre-add guard (src/util/debridAddGuard.ts) that both front ends already have the data for (seeders, per-source health, and cache status all known before the click) and refuses the add outright with an explanatory notice instead of letting it get stuck.
  • Client-side only (TUI + web button) — the raw /api/add route is unchanged, since the actual bug is the button click, not scripted API use.
  • A source with no swarm health reporting (seeders: 0 meaning "unknown", per resultFilter.ts's existing convention) is never blocked, and an already-cached result is never blocked regardless of seeders.

Test plan

  • npm test — full suite (3348 tests) passes, including new addPlan cases for blocked/cached/unhealthy-source/P2P-exempt
  • npm run typecheck
  • npm run lint (only the pre-existing react-hooks/exhaustive-deps warning)
  • npm run build

🤖 Generated with Claude Code

https://claude.ai/code/session_0147i7Q9sRkmaCfjpBjuBQaN

A zero-seed torrent that isn't already cached in the debrid provider never
finishes: it just occupies one of the account's few concurrent slots
forever (TorBox's own stall detection only fires after a multi-minute
timeout, by which point the slot is already gone). On a plan capped at a
handful of concurrent downloads, a few of these permanently blocks every
future add.

Seeders and cache status are already known before the user clicks add on
both front ends, so a shared guard (src/util/debridAddGuard.ts) now
refuses the add outright instead of letting it get stuck.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147i7Q9sRkmaCfjpBjuBQaN
@WarlaxZ
WarlaxZ merged commit df1153e into main Sep 3, 2026
6 checks passed
@WarlaxZ
WarlaxZ deleted the guard-debrid-zero-seed-add branch September 3, 2026 07:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants