Duplicate issues not updating properly in team response phase

[chunweii]

https://user-images.githubusercontent.com/47494777/150458743-4ed55c32-3aee-4466-b619-63e4471d11b0.mp4

As shown in the video, if I try to update the labels and assignees of an issue quickly, only the latest label/assignee that is changed will be updated in the other duplicate issues.

Sometimes, selecting a label too quickly can also cause it to revert back to the original. (See 0:02 to 0:04)

A workaround is to wait for a while before updating another label or assignee. However, users may not know how long to wait and if they are not aware of this issue, then they might change the labels/assignees too quickly and forget to check the status of the duplicate issues.

[gycgabriel]

Similar to #801

[gycgabriel]

I'm guessing this is due to the changing of multiple github labels from individual functions get interleaved and only the last running function overrides the previous label change and restores the previously changed label.

[dingyuchen]

I have since realised that this is due to the nature of asynchronous HTTP requests. One solution clued in by this blog is to use the native HTML Form API, that supposedly cancels in-flight requests when there is a new update. Another way is to create a mutation library that manages the interrupts, devs might want to attempt it as a challenge? :)

Either way is seems like we can reproduce this by simply throttling network speed in the developer's console.

[Arif-Khalid]

Is there a reason we don't simply disable the sources of changes while waiting for github's response? While it might reduce the speed at which someone submits their issues, I argue it is better than the rolling back of their changes.