Parent issue: #275

Endpoint: POST http://localhost:3001/v1/torrent/upload

Change torrent details endpoint returning 409 Conflict when the user tries to upload a torrent whose canonical info-hash already exists in the database. That means at least one torrent with the same canonical info-hash was already uploaded.

Context

After merging this PR #269, the Index stores the canonical infohash and the original infohash.

The infohash of the uploaded torrent might change if it contains a non-standard field in the info dictionary.

Problem

If you submit a new POST, the user will see this error:

This is the JSON response 400:

{
    "error": "A torrent with the same canonical infohash already exists in our database."
}

But If you submit the same torrent again, you will see a different error:

{
    "error": "This torrent already exists in our database."
}

Because the new "original" torrent was also included in the database. But we do not now if it was the first one or the second one. Maybe for this case we should show a third error:

"A torrent with the same original and canonical infohash already exists in our database."

Solution

Although it works, I think we should:

• Return a 409 Conflict
• Include the canonical info-hash in the error message.
• Introduce the third error message.
• Ideally, we should change the frontend to link to the torrent details page (using the canonical info-hash). By the way, @da2ce7, we are not using error codes, which means we are forced in the frontend to parse error messages to understand the error. I think error responses should be like:

{
    "error": {
        "code": 111
        "message": "A torrent with the same canonical infohash already exists in our database."
        "data": {
            "infohash: "8980574938ccaeb3659408045bf1b77e127d740b"
            "canonical_infohash: "613acafb92303cb95446e16a75bb2608e7fccc21"
        }
    }
}

Priority

This is not a bug. It can be misleading for UI users and API users.

• For end users: they do not know which one is the previously uploaded torrent.
• For API consumers: they might think their request is not well-formed due to the 400 Bad Response.

cc @da2ce7