Bug: RPC returns "success" for non-existent hashes.

[promythyus]

Running transmissioncli on version 2.03 (11030), upon sending the following RPC request:

Code: Select all

{"method":"torrent-verify","arguments":{"ids":["63c5d03c8111cf499d18c18d33e61c9b81d92270"]},"tag":4}

where the hash "63c5d03c8111cf499d18c18d33e61c9b81d92270" does not exist in this Transmission, it responds with:

Code: Select all

{"arguments":{},"result":"success","tag":4}

Similarly,

Code: Select all

{"method":"torrent-get","arguments":{"ids":["63c5d03c8111cf499d18c18d33e61c9b81d92270"],"fields":["recheckProgress"]},"tag":8}

responds with:

Code: Select all

{"arguments":{"torrents":[]},"result":"success","tag":8}

In the RPC spec, 2.2.1 says that "A required "result" string whose value MUST be "success" on success, or an error string on failure.". No definition of "success" is provided, though I would deem this behaviour non-successful, as you can't verify or check progress on a torrent that doesn't exist, and an error string should be returned.

Recipe:
1. Set up transmissioncli 2.03 (11030) with RPC access.
2. Send aforementioned request string.
3. Recieve response, it is incorrect.

Thoughts?

[blacke4dawn]

Version 2.03 is very old so I doubt it will be fixed. Try a later one.

[killemov]

Although technically you are correct, your point is moot. In practice the hash could only come from the daemon itself. You don't manually type in a hash for issuing commands on a torrent.