In the 2018 competition, one broker overflowed the ID limit and failed to complete a game. The problem is outlined in Issue #978. We have implemented, tested, and deployed a fix for this problem, which is to re-cycle the IdGenerator at the start of each new session. This works for the sample broker; the id values for new domain types (tariff specifications, orders, etc.) start from zero (plus the offset supplied by the server at login) in each session when the broker is run with --repeat-count > 1. It should work for your broker as long as you are not creating objects using the IdGenerator in the first session and expecting those objects to persist across multiple sessions. If you are doing this, you may want to either re-create them (or increment the IdGenerator past them), or use your own ID scheme for them. Note that ID value collisions across types will probably not cause problems as long as you are (a) not saving the colliding types in the state log and expecting to re-create those objects from the state log in post-game analysis; (b) not trying to use existing repos (like TariffRepo or OrderbookRepo) for colliding types; and (c) not sending instances of colliding types to the server (unlikely to be a problem because the server would not know anything about types that exist in the broker but not the server).
This update is implemented in the new 1.6.0-SNAPSHOT code, which you will see if you build your broker with powertac-parent version 1.6.0-SNAPSHOT. See sample-broker/pom.xml to see what this should look like.
To run the updated server, please download the latest server-distribution version 1.6.0-SNAPSHOT. This version will track changes we make as we fix issues and implement features for the 2019 competition.
As always, please let us know if you have questions or run into problems with this update.