Unhandled exceptions in fort #436
Comments
SapiensAnatis
added
bug
|
Have not been able to trigger smithywyrms manually, could be a race condition? |
Adds some logging to dump the state of the fort when this exception occurs. Contributes to #436
Investigating as part of #436. Adds some debug logging to indicate the state of the fort at the time these exceptions get thrown.
|
'Building not finished upgrading' appears to be a repeated request, but with a different request token?
On the second request, the BuildEndDate is the unix epoch so we fail the first part of this check: |
|
'Not enough builders' looks like it could be a logic error in how we calculate the available builders. We assume that any building that is under construction consumes a builder, even if it is finished: But after the debug logging was added, I noticed it affects new players building low-level facilities that finish quickly. After trying this myself, I noticed that if you build a facility that takes e.g. 5 seconds, your builder count goes to 3/4, but when it finishes, the client self-increments the builders back to 4/4. I think we need to change |
Contributes to #436. Changes the used carpenter count calculation to be based on the number of buildings currently under construction which aren't finished, rather than any building that has a non-zero BuildEndDate. This is because if you start an upgrade that takes e.g. 10 seconds, we report you have 3/4 builders. That's fine. But when the client sees that build complete using its internal timer, it then believes 4/4 builders are available, but we currently would say it's still 3/4 until you actually call levelup_end by tapping the building. This desync was causing the FortBuildCarpenterBusy exception.
Contributes to #436. Changes the used carpenter count calculation to be based on the number of buildings currently under construction which aren't finished, rather than any building that has a non-zero BuildEndDate. This is because if you start an upgrade that takes e.g. 10 seconds, we report you have 3/4 builders. That's fine. But 10 seconds later, when the client sees that build complete using its internal timer, it then believes 4/4 builders are available, but we currently would say it's still 3/4 until you actually call levelup_end by tapping the building. I believe this desync is what causes the FortBuildCarpenterBusy exception.
The fort services throw a lot of unhandled exceptions
Some examples:
Need to investigate. Are we doing something wrong and is the client calling these endpoints because it thinks the request is valid when it isn't?
If the client is allowing players to do these actions and expecting the server to reject them, we should rework the code to reject them before we start processing the request and not throw an unhandled exception.
The text was updated successfully, but these errors were encountered: