fix(rtorrent): auto-detect and use load.throw methods when available

[Copilot]

Problem

Following the fix in commit 082d3e9 (#930) that addressed load.start_throw usage in file-based torrent addition, the URL-based torrent addition method (addTorrentsByURL) was still using the deprecated load.start_throw and load.throw commands. This caused failures when adding torrents via URL from external applications like Sonarr when users removed the stubbed commands from their rTorrent configuration.

As reported in https://github.com/jesec/flood/commit/2c5da60d1abcc493f338571f02cf41a22a702d95#commitcomment-168637106:

I tested to remove the stubbed commands from my rtorrent. It failed to add a file when my sonarr sent a download request to flood. There is one more place in the same file with "start_throw" on line 168.

Solution

This PR implements runtime detection for load.throw and load.start_throw method availability:

Key Implementation:

• Added detectLoadThrowSupport() method that caches the detection result
• Tests load.throw availability and checks for JSON-RPC error -32601 (method not found)
• Prefers .throw methods when available (provides better error reporting)
• Falls back to load.start/load.normal when .throw methods are not supported
• Detection happens only once per service instance

Before:

if (this.clientRequestManager.isJSONCapable) {
  methodName = start ? 'load.start_throw' : 'load.throw';
} else {
  methodName = start ? 'load.start' : 'load.normal';
}

After:

const supportsThrow = await this.detectLoadThrowSupport();
const methodName = start
  ? supportsThrow ? 'load.start_throw' : 'load.start'
  : supportsThrow ? 'load.throw' : 'load.normal';

The code now:

• Automatically detects .throw method support at runtime
• Uses .throw methods when available for better error reporting
• Falls back gracefully when .throw methods are not available
• Works with both addTorrentsByFile and addTorrentsByURL

Impact

This solution provides the best of both worlds:

For users with upstream rTorrent (with .throw support):

• Gets better error reporting from .throw methods
• No configuration changes needed

For users with older rTorrent or without .throw methods:

• Automatically falls back to load.start/load.normal
• No stub commands required
• No configuration changes needed

For all users:

• Works seamlessly with external applications (Sonarr, Radarr, etc.)
• Automatic detection eliminates configuration complexity
• Stub commands in README remain valid for explicit configuration preferences

Testing

• ✅ TypeScript type checking passed
• ✅ ESLint passed with 0 warnings
• ✅ Runtime detection logic handles both supported and unsupported cases

Fixes jesec/flood#932

Original prompt

---

This section details on the original issue you should resolve

<issue_title>load.start_throw is still used</issue_title> <issue_description>> I tested to remove the stubbed commands from my rtorrent. It failed to add a file when my sonarr sent a download request to flood. There is one more place in the same file with "start_throw" on line 168.

Originally posted by @mirolm in 2c5da60</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes jesec/flood#932

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jesec]

@copilot Deep dive into https://github.com/rakshasa/rtorrent/blob/master/src/rpc/jsonrpc.cc and related implementations.

We should only use load.start / load.normal if .throw versions are not available (JSONRPC_METHOD_NOT_FOUND_ERROR). Do the check only once, however, and no need to do it separately, if one .throw is available assume both are available.

[jesec]

@copilot and don't commit package-lock.json. We use pnpm.

[Copilot]

@copilot Deep dive into https://github.com/rakshasa/rtorrent/blob/master/src/rpc/jsonrpc.cc and related implementations.

We should only use load.start / load.normal if .throw versions are not avail...

Implemented runtime detection for .throw method support. The code now:

• Checks if load.throw is available (only once, result is cached)
• Returns false only for JSON-RPC error -32601 (method not found)
• Returns true for any other error (method exists but failed for other reasons)
• Uses .throw methods when available for better error reporting
• Falls back to load.start/load.normal when not supported

See commit 033a02f

@copilot and don't commit package-lock.json. We use pnpm.

Fixed - package-lock.json was removed and added to .gitignore in commit 0ad4457