# Keep an Up-To-Date Game Deadline
Make sure you have everything you need before proceeding:
- You understand the concepts of Protobuf.
- Go is installed.
- You have the checkers blockchain codebase with the game FIFO. If not, follow the previous steps or check out the relevant version (opens new window).
In this section, you will:
- Implement a deadline.
- Work with dates.
- Extend your unit tests.
In the previous section you introduced a FIFO that keeps the oldest games at its head and the most recently updated games at its tail.
Just because a game has not been updated in a while does not mean that it has expired. To ascertain this you need to add a new field to a game,
deadline, and test against it.
# New information
To prepare the field, add in the
StoredGame's Protobuf definition:
To have Ignite CLI and Protobuf recompile this file, use:
On each update the deadline will always be now plus a fixed duration. In this context, now refers to the block's time. Declare this duration as a new constant, plus how the date is to be represented - encoded in the saved game as a string:
# Date manipulation
Helper functions can encode and decode the deadline in the storage.
Define a new error:
Add your date helpers. A reasonable location to pick is
sdkerrors.Wrapf(err, ...)conveniently returns
At the same time, add this to the
Add a function that encapsulates how the next deadline is calculated in the same file:
# Updated deadline
Next, you need to update this new field with its appropriate value:
At creation, in the message handler for game creation:
After a move, in the message handler:
Confirm that your project still compiles:
# Unit tests
After these changes, your previous unit tests fail. Fix them by adding
Deadline wherever it should be. Do not forget that the time is taken from the block's timestamp. In the case of tests, it is stored in the context's
ctx.BlockTime(). In effect, you need to add this single line:
Also add a couple of unit tests that confirm the
GetDeadlineAsTime function works as intended (opens new window) and that the dates saved on create (opens new window) and on play (opens new window) are parseable.
# Interact via the CLI
There is not much to test here. Remember that you added a new field, but if your blockchain state already contains games then they are missing the new field:
This demonstrates some missing information:
In effect, your blockchain state is broken. Examine the section on migrations to see how to update your blockchain state to avoid such a breaking change. This broken state still lets you test the update of the deadline on play:
In the same vein, you can create a new game and confirm it contains the deadline.
To summarize, this section has explored:
- How to implement a new
deadlinefield and work with dates to enable the application to check whether games which have not been recently updated have expired or not.
- How the deadline must use the block's time as its reference point, since a non-deterministic
Date.now()would change with each execution.
- How to test your code to ensure that it functions as desired.
- How to interact with the CLI to create a new game with the deadline field in place
- How, if your blockchain contains preexisting games, that the blockchain state is now effectively broken, since the deadline field of those games demonstrates missing information (which can be corrected through migration).