Creating a DSR with an ID causes weird behavior

[ocket8888]

This Bug Report affects these Traffic Control components:

• Traffic Ops

Current behavior:

When creating a DSR (in both APIv3 and APIv4) you may optionally specify an ID. In doing so, Traffic Ops will treat it as a PUT request for the purposes of validation. This means that it will look for an existing Delivery Service with that ID, and try to verify that the status of the DSR to be created is in a status that is a valid transition from the status of the existing Delivery Service - which can lead to false negatives in the validation of the DSR. Or, if the ID is not one that matches any existing DSR, a 400 Bad Request error is returned to the client with no real information about what went wrong (unknown error in v3 and simply Bad Request in v4).

Expected behavior:

Fields that aren't required should be ignored, and should not affect validation.

Steps to reproduce:

$ topost -kp deliveryservice_requests '{"status": "submitted", "changeType": "create", "deliveryService": {}, "id": 10000}'
{
    "alerts": [
        {
            "text": "unknown error",
            "level": "error"
        }
    ]
}

[ocket8888]

Incidentally, this also manifests when creating a DSR with a createdAt and/or lastUpdated. If, for example, set to the empty string, it will fail to decode as JSON and send back a 400 Bad Request response (albeit this time with a somewhat more helpful message).

Also, I didn't test it, but I suspect this means that one can submit invalid edits to a DSR by simply swapping out the ID in the body with the ID of a DSR for which the edits would be valid, which is a much bigger deal, but also probably pretty hard to get wrong.