race condition during configuration reading from db and setting to db
When there is a series of *-set commands executed during 1second it may appear that Kea starts reading modifications from the db in the middle of this second. So it will read only part of modifications. In next turn Kea checks timestamp of modifications: ts > last_ts. Unfortunately timestamps have 1s resolution so the other part of changes will not be noticed as they happend in the same last_ts.
This can happen quite frequently when config-fetch-wait-time is set to 1s. In that case Kea checks modifications every second so there is high chance that it will get in the middle of series of modification.
It is exposed by Forge test: tests/dhcpv6/kea_only/config_backend/test_cb_v4_options.py::test_multiple_subnet_option
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information