Removing container in PUT /flows/<flowid> doesn't unset it

[samdbmg]

If you create a Flow with a container property set, and then try and remove the container property, I'd expect it to get removed, but it doesn't.

For example:

PUT /flows/e6d4de80-9a09-4ea8-a214-c16cc354ca68
{
  "id": "e6d4de80-9a09-4ea8-a214-c16cc354ca68",
  "source_id": "42088fcb-ce09-4215-baeb-2a18691c081d",
  "label": "My Flow",
  "container": "video/mp2t",
  "format": "urn:x-nmos:format:multi"
}

Then do (note the absence of the container property)

PUT /flows/e6d4de80-9a09-4ea8-a214-c16cc354ca68
{
  "id": "e6d4de80-9a09-4ea8-a214-c16cc354ca68",
  "source_id": "42088fcb-ce09-4215-baeb-2a18691c081d",
  "label": "My Flow",
  "format": "urn:x-nmos:format:multi"
}

I'd expect a GET /flows/e6d4de80-9a09-4ea8-a214-c16cc354ca68 to omit the container property, given the PUT semantic of replacing the object with the given body, but container is still there.
I've not tested this with any other property, but I could imagine the same bug affecting others too.

[danjhd]

Acknowledged. Thank you. You are correct this behaviour will happen for any property used in a previous PUT that is then omitted in the follow up PUT.
This is not how this should behave.
As you suggest the correct behaviour should be to remove a property if it is not present in the follow up PUT.

[danjhd]

As a workaround in the meantime the solution would be to delete the flow and then re-create it. Be aware that deleting a flow will delete any associated segments.

[danjhd]

Resolved in v3.0 release