getUsedCapacity fast-cache causes double counting of resources

  • I spent a few hours today tracking down why transfering with a specific amount was failing and I was able to isolate it to the fast cache that exists for Store.getUsedCapacity. It appears that after using the function in a tick, resources will then be double counted on the store object in a number of cases.

    It looks like this may have been modified on PTR:

    Repro steps:

    1. Fill a container with 900 resources.
    2. On a container, use
    3. Attempt to transfer 300 resources to the container.

    Expected: Transfer from creep to container returns a success error code.

    Actual: It will fail with ERR_FULL as utils.calcResources returns 1800 resources in the container instead of 900.

  • Dev Team

    @azaril Thanks for the report, we'll take a look

  • Dev Team

    @azaril said in getUsedCapacity fast-cache causes double counting of resources:

    I just failed to reproduce the issue on production:


    [10:56:26 AM][shard2]900

    [10:56:26 AM][shard2]0

    It returns OK and being executed successfully.

    Using transfer without the third parameter while holding 300 energy works either.

    Any idea what I might miss?

  • I had only reproduced it on a local private server - I have not tried on production.

  • Similar issues, but on local private server. I was using on a Store object, and the key _sum appears before all other valid resources.