Prevent double-clicking the green button to act in future phases

[sleepyfoxen]

On a poor connection or through an accidental double-click, your vote for approving the mission might be interpreted as a vote for whether the mission succeeds.

Attaching an idempotency token to each voting round that is checked server-side will prevent a situation where repeated events over the websocket cause inadvertent results.

[vck3000]

Indeed. A simple solution could be to timeout the front end buttons for half a second before sending out a request.

[mybaldbird]

How about just moving the buttons so that approve and reject don't overlap succeed and fail?

[sleepyfoxen]

How about just moving the buttons so that approve and reject don't overlap succeed and fail?

A server-side variant of this is to "split" yes and no (for both votes¹²) into approve, reject (mission votes) and succeed, fail (mission success). I never got round to making a PR for this though, and I don't know whether it would still be considered for merging.

[vck3000]

@mybaldbird Moving the buttons at this stage would cause a lot of confusion. If we are to reposition the button, we should introduce it in the next rewrite. If either of you guys are interested in helping, give me a quick pm.

@sleepyfoxen I changed it from approve, reject, succeed and fail to just yes and no. This decision was made to create an easier API for bots, but also on the frontend. Since there are only ever two buttons in play, it was easier and clearer at the time to have them as the same emit message. In the next rewrite however, with better structure, we may be able to change this and include the accepted emit messages for the current game phase. This would allow users to play on a command line for example. But this isn't a necessary feature at the moment.

[vck3000]

Revisiting this, there's a canonical simple solution to this. A sequence number. Would be good to implement this.