Closed Alenar closed 1 month ago
3 files ±0 43 suites ±0 8m 34s :stopwatch: ±0s 1 012 tests +9 1 012 :white_check_mark: +9 0 :zzz: ±0 0 :x: ±0 1 110 runs +9 1 110 :white_check_mark: +9 0 :zzz: ±0 0 :x: ±0
Results for commit 70a8a616. ± Comparison against base commit 3b542fdc.
:recycle: This comment has been updated with latest results.
Content
This PR changes the beacon used for the
CardanoTransactions
signed entity type:CardanoDbBeacon
(aka: network, epoch, immutable file number)This changes decouples the production of cardano transactions signatures and proofs from the immutable file number and the cardano node database structure. Allowing us to go closer to the tip of the chain since, with a adapted block streamer, we won't have to wait for a immutable to be complete update our stored transactions.
In depth
cardano_transactions_signing_config
.CardanoTransactionsSnapshot
artifact: replacebeacon
withblock_number
(note: the epoch can still be fetched if it's wrapped by aSignedEntity<T>
and is added to the related messages).ProtocolMessage
andCardanoTransactionsProofsMessage
: renamelatest_immutable_file_number
tolatest_block_number
.BlockScanner
trait: use aOption<ChainPoint>
for its lower bound and aBlockNumber
for the upper bound. Previously it used aImmutableFileNumber
for both.CardanoBlockScanner
: ignore the bounds given as parameter and compute them itself (lower bound from db and upper bound take all completed immutables) since it still works using immutables files and there's no way go get the immutable file that contains a given block from the chain.TransactionsImporter
andBlockRangeRootRetriever
traits, to use aBlockNumber
instead of aImmutableFileNumber
.CardanoTransactions
from Aggregator database since their beacons changed.signed_entity
instead of relying on the deprecatedbeacon
property.Pre-submit checklist
Comments
This would have been considered a network breaking change on a stable signed entity type.
Issue(s)
Closes #1697