Creating and publishing a scheduled change request shows duplicate entries in the 'scheduling' tab when versioning enabled

[matthewelwell]

To reproduce:

1. In an environment with versioning enabled, create a change request scheduled for the future
2. Navigate to the 'Change Requests' tab and notice that there is only one change request
3. Publish the change request
4. Navigate to the 'Scheduling' tab and notice that there are 2 identical scheduled changes pending

[matthewelwell]

I've looked into this, and the underlying cause is that there are 2 change_sets for the change request, one that is deleted and one that is not. These 2 are identical. The fact that there are 2 change sets, means that the underlying SQL is returning 2 duplicate rows.

I will look to resolve this on the back end to prevent this, however, the issue is caused by the fact that the FE is doing a PUT immediately after the POST request, as you can see in the following screenshots.

In fact, from looking at the payloads, the API is doing the correct thing here. The FE is sending the PUT with the same payload as the post (i.e. it's not including the id of the version change set) so the API is deleting the one that was no longer included in the PUT request and creating a new one.

I'll still need to prevent the API from returning duplicates here to account for when multiple change sets are a valid use case but the immediate fix should be done on the FE.