`get_active_witnesses` and `get_witness_schedule` extended - alternative version
This is an alternative implementation to !730 (closed) (this branch is based on that one, so there are some common changes).
Needs test-tools!99 (merged) and schemas!31 (merged)
Changes affect get_active_witnesses
and get_witness_schedule
calls in various APIs. The calls have extra boolean parameter include_future
that defaults to false
(where possible). When called with such value the APIs behave as before the change (unless stated otherwise), with one exception.
Call to get_witness_schedule
, even with false
, returns values taken from future schedule for current_virtual_time
and next_shuffle_block_num
, since only such values are relevant (values from active schedule are "in the past"). It fixes a bug in the API introduced by HF26.
The following happens when the calls are made with true
in parameter.
database_api.get_witness_schedule
(actual implementation for other APIs):
- result includes new list
future_shuffled_witnesses
that is the same ascurrent_shuffled_witnesses
, except it is taken from future schedule - result might include
future_changes
, but only if there are any changes between active and future schedules. Only the changed fields are elements offuture_changes
, f.e. ifmajority_version
is different between active and future schedules, but everything else stays the same,future_changes
will containmajority_version
field with value from future schedule.
database_api.get_active_witnesses
(actual implementation for other APIs):
- result includes new list
future_witnesses
that is the same aswitnesses
, except it is taken from future schedule
condenser_api.get_witness_schedule
:
- same changes as in
database_api
condenser_api.get_active_witnesses
:
- since routine returns single list, there was only a choice between different bad solutions. The one was selected that keeps old behavior for default parameter, which is to concatenate
witnesses
andfuture_witnesses
into single list, separated with empty element. Yes, it is no good but other choices were worse.database_api
version should be used by callers directly instead.
wallet_bridge_api.get_witness_schedule
:
- now requires parameter. Since that API is for wallet, new requirement should be ok. Wallet obviously honors new interface.
- same changes as in
database_api
wallet_bridge_api.get_active_witnesses
:
- now requires parameter
- same changes as in
database_api
wallet_api.get_active_witnesses
:
- now requires parameter. Since mechanism used for that API does not handle default parameters, there was no option to have default value.
- the value returned changed from vector to the same as in
database_api
. It should be ok, since wallet should not be used by scripts, those can calldatabase_api
directly from node.
On top of above changes there are two more calls worth mentioning.
debug_node_api.debug_get_witness_schedule
:
- it did not change, there is no new parameter, it does not correct values of
current_virtual_time
andnext_shuffle_block_num
either (it returns raw value held in state object)
debug_node_api.debug_get_future_witness_schedule
:
- new call, returns unchanged raw value of schedule state object, just the one holding future schedule