feat(serve): per-torrent seed time over the API - #186
Open
ralyodio wants to merge 1 commit into
Open
Conversation
A seedbox rarely wants one seed policy for everything. --seed-time is daemon-wide, so keeping a single release alive for a month on a box that drops seeds after two hours meant restarting the daemon or running two. POST /add now takes an optional seedTime (the --seed-time grammar: "30d", "2h"; 0 = never stop) that belongs to that torrent alone, and a new seed-time control action sets or clears it later, including on a download still in flight. The value rides on the queue item into its history entry, so it survives restarts the same way completedAt does. The reaper prefers a torrent's own limit over the daemon-wide one and now runs in serve and watch even without --seed-time, where it only acts on torrents that carry a limit of their own. GET /downloads reports seedTimeMs and seedUntil on anything that has one, so a caller can see the setting took. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SKAohrRkqLKVQL2cGCAkR5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
--seed-timeis one policy for the whole daemon. A seedbox that drops seeds after a couple of hours has no way to keep one release alive for a month short of restarting the daemon with a different flag or running a second one. The headless API grew per-torrent buttons in #105; this gives it a per-torrent seed limit to match.What
POST /addtakes an optionalseedTimein the--seed-timegrammar ("30d","2h", a bare number is seconds;0= never stop this one). It belongs to that torrent alone and wins over the daemon-wide flag. An unusable value is a 400 and nothing is added.seed-timecontrol action sets or clears it later (seedTime: ""clears), including on a download still in flight.completedAtdoes.serveandwatcheven without--seed-time; with no daemon-wide limit it only acts on torrents carrying their own, and with neither it does nothing.seed(the one-shot local seeder) is unchanged.GET /downloadsreportsseedTimeMson downloads andseedTimeMs+seedUntilon seeds that have their own limit, so a caller can verify the setting took. Torrents inheriting the daemon default report nothing new, since that default is the caller's to know.Watch mode is deliberately untouched: a
.magnetfile has nowhere to carry a limit, and the API is where a seedbox sets one anyway.Tests
npm run typecheckclean,npm test392 passing (373 before). New coverage: reaper precedence (own limit over daemon-wide in both directions, 0 = never, per-torrent with no daemon limit, nothing with no limit at all),extractSeedTimeon every input shape,/addforwarding and rejecting, theseed-timecontrol action end to end, the status payload, andsetSeedTimeon both a history entry and an in-flight download.馃 Generated with Claude Code
https://claude.ai/code/session_01SKAohrRkqLKVQL2cGCAkR5