When the lot-city connection fails, all lots on the lot server are closed and released to ensure consistency, and to release those lots' claims in the database. However, if the city is still alive, it will still have allocations for these lots set up in LotAllocations, meaning that the city server believes the lot server is hosting the lot when it has already shut down.
When a user attempts to re-open their lot after this, LotAllocations believes it is already open, and tells the user to connect to it on the lot server. However, when the user connects to the lot server, they are booted off immediately because the lot is not actually being hosted.
Any additional lots will start and allocate as normal.
Solution:
Attempt to re-establish connection a few times before doing the city panic. (disconnecting all lots is not something we want to do often.
Double check that a lot has been claimed when obtaining an allocation saying that it is open on a specific lot server. If it is not, remove the allocation and try creating a new one instead.
We may need to double check this going the other way. What if the city believes a lot is not allocated, but it is open on the lot server? Should it reroute to the one that is open, or attempt to close the old allocation, assuming the city server has been restarted?
When the lot-city connection fails, all lots on the lot server are closed and released to ensure consistency, and to release those lots' claims in the database. However, if the city is still alive, it will still have allocations for these lots set up in LotAllocations, meaning that the city server believes the lot server is hosting the lot when it has already shut down.
When a user attempts to re-open their lot after this, LotAllocations believes it is already open, and tells the user to connect to it on the lot server. However, when the user connects to the lot server, they are booted off immediately because the lot is not actually being hosted.
Any additional lots will start and allocate as normal.
Solution: