restore get_block_header_state
endpoint for usage both pre and post Savanna activation
#40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the past,
get_block_header_state
returned the pre-Savanna (legacy) block header state. Parts of this response are incompatible with the internals of the new Savanna block state. Originally the plan was to simply remove theget_block_header_state
endpoint, but some versions of eosjs (including thelatest
one, 22.1.0, apparently downloaded some 17k times in the last week) require operation of this endpoint given certain values ofblocksBehind
otherwise eosjs will be unable to push a transaction.So instead, restore the endpoint with some behavioral differences. No matter whether Savanna has been activated or not,
get_block_header_state
in Spring 1.0 will return a response containing all fields but with onlyblock_num
,id
,header
, andadditional_signatures
filled out. Other fields will still exist but will be empty or zero. Additionally, the endpoint will consider both reversible and irreversible blocks. This latter tweak helps guard against a race condition in eosjs between callingget_info
and thenget_block_header_state
whenblocksBehind
is a low number such as 2 or 3.An example response with the limited filled fields looks something like,
I've confirmed with eosjs 22.1.0, 21.0.4, and 20.0.3 that operation works as expected. (20.0.3 does not use
get_block_header_state
fortransact()
though, instead just always callingget_block
)Resolves #39