Possible race condition in PluginaPage::getNextPermidAndRank

[blockhead]

This method queries for the max permid, without setting any locks, setting up for a possible race condition.

[boutell]

[Backstory: if two people add a slot to an area at the same time, won't they get the same permid and step on each other's work? Yep, they probably will]

I think you're right. We'll be on it soon. There is a lock mechanism in the reorganize feature code that could be used here. The fix should be backported to the stable branch.

[boutell]

There is a race condition here, however the worst case is losing your save if two people are editing the same area at the same time. Right now we have a larger problem there, which is that two people aren't warned that they are editing the same area (or page/virtual page in general) at the same time. We'll look at hitting this problem (the solution to which requires changing permids to be GUIDs rather than 32-bit integers) in the same timeframe with better concurrent workflow in general.

Of course we'll fix race conditions of the "if two people do this, the entire page tree comes unmoored from the universe and floats toward a black hole" variety in the much more immediate term (:

[tboutell]

Fixed in [2974]: no more race conditions when two people edit the same area. That is, you can both save your changes and they will wind up consecutive in the history, with no risk of one person's work being gone for all time. (There was never any danger to the page tree so this was not a super-high priority.)

Of course it would be more helpful to actually warn when someone else is editing which is something we should address in the future. But locks for safe concurrency are always of the good.

This lock is just on the particular page, so it should not have any performance impact on people editing elsewhere in the site on a site like FM with many active editors.

(The lock is in newAreaVersion, which is the one true blessed API for doing things to areas, including singleton slot areas.)