Inconsistencies in MCP seconding and standing concerns

[apiraino]

Looking at the comment history of compiler-team#893:

• A concern was raised after it was seconded. I think this blocked the closing but did not remove the fcp label
• I seconded the MCP (again!) while it had unresolved concerns, did anything change in the DB state or did just a comment on Zulip misfired?
• when seconding an MCP with standing concerns, a good UI could be to say "nope" (I would not wipe all concerns automatically)

cc @Urgau

[Urgau]

A concern was raised after it was seconded. I think this blocked the closing but did not remove the fcp label

This is expected. The major change handler is state-less, it relies purely on labels, if we were to remove the final-comment-period label when a concern is raised we wouldn't know if it should be re-added or not when all the concerns are resolved.

I seconded the MCP (again!) while it had unresolved concerns, did anything change in the DB state or did just a comment on Zulip misfired?

There is no issue with seconding a MCP multiple times, each time it will send a another Zulip notification, and if there are unresolved concerns it will block the auto-closing and tell the user.

I would also note that technically everything that happend before it was accepted the first time is no longer taken into account. Re-opening a closed MCP restarts everything from the start.

when seconding an MCP with standing concerns, a good UI could be to say "nope" (I would not wipe all concerns automatically)

We could do that.