Problem description
Hedera testnet will be reset every quarter, starting from the 26th of January. This will wipe out all Guardian state from the testnet, including:
- Tokens
- Messages
- Topics
- Balances of user account (but the accounts themselves are not affected). (TBD - is this true?)
Guardian currently assumes that all records on Hedera (whether testnet or mainnet) are permanent and immutable, therefore Hedera reset presents a serious issue to the continuity of the Environmental projects data stream, their trust chain, and general Guardian instance functioning.
Requirements
Create a seamless continuing operation of Guardian instances across Hedera resets, maintaining Guardian functionality and keeping data accessible (only) from within Guardian as if no resets have happened.
-
Adapt Guardian to tolerate Hedera resets by making it distinguish between 'archive' data and 'live' data. The former is Hedera-stored data (and their corresponding IDs) which existed prior to the reset, but is no longer available in Hedera. The latter is 'current' data which is available in Hedera. These two data types will be handled differently:
- 'Dry run'-like mode will be used for 'archive' data, i.e. when guardian performs operation on 'archive' data it does not reach out externally (to Hedera).
- Normal mode of operation applies to 'live' data.
-
Review Guardian Hedera interactions to ensure that all data stored in Hedera is cached in Guardian DB.
-
Introduce ability to arbitrarily designate data to be 'archive' data based on the data/time. This will be used every time there is a testnet reset to cut-off the archive data from live data.
Definition of done
- Functionality implemented as above
- Documentation
Acceptance criteria
Users of Guardian work seamlessly (only) via their instances' API and/or UI, agnostic to the resets that have happened on Hedera so long as they monitor Hedera reset schedule and configure guardian archvie/live data distinction accordingly.
Problem description
Hedera testnet will be reset every quarter, starting from the 26th of January. This will wipe out all Guardian state from the testnet, including:
Guardian currently assumes that all records on Hedera (whether testnet or mainnet) are permanent and immutable, therefore Hedera reset presents a serious issue to the continuity of the Environmental projects data stream, their trust chain, and general Guardian instance functioning.
Requirements
Create a seamless continuing operation of Guardian instances across Hedera resets, maintaining Guardian functionality and keeping data accessible (only) from within Guardian as if no resets have happened.
Adapt Guardian to tolerate Hedera resets by making it distinguish between 'archive' data and 'live' data. The former is Hedera-stored data (and their corresponding IDs) which existed prior to the reset, but is no longer available in Hedera. The latter is 'current' data which is available in Hedera. These two data types will be handled differently:
Review Guardian Hedera interactions to ensure that all data stored in Hedera is cached in Guardian DB.
Introduce ability to arbitrarily designate data to be 'archive' data based on the data/time. This will be used every time there is a testnet reset to cut-off the archive data from live data.
Definition of done
Acceptance criteria
Users of Guardian work seamlessly (only) via their instances' API and/or UI, agnostic to the resets that have happened on Hedera so long as they monitor Hedera reset schedule and configure guardian archvie/live data distinction accordingly.