ingest/ledgerbackend: Fix captive core bug where --start-at-hash parameter is omitted #3265
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.
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
In #3201 we assumed it was possible to omit the
--start-at-hash
parameter when starting from the genesis ledger. However, Stellar Core actually fails when attempting that command. The--start-at-hash
parameter is always required when using--start-at-ledger
.This means that if we want to stream from the genesis ledger we need to determine the either the horizon db or the history archives.
In the case that the first checkpoint has not been published we attempt to invokestellar-core run --in-memory
without any start parameters. The expected behavior from stellar core is that it will join the network and stream from the nearest checkpoint boundary, which in this case would be the genesis ledger since the first checkpoint has not been published yet.[edit:] I tested the behavior of
stellar-core run --in-memory
on a stand alone network and unfortunately stellar core will keep buffering ledgers until the first checkpoint is published before it starts streaming any ledgers. Therefore it does not make any sense to use this work around.Known limitations
N / A