Releases: stellar/go
Horizon v2.5.1
Upgrading to this version from <= v2.1.1 will trigger a state rebuild. During this process (which can take up to 20 minutes), Horizon will not ingest new ledgers.
Horizon v2.5.0
Upgrading to this version from <= v2.1.1 will trigger a state rebuild. During this process (which can take up to 20 minutes), Horizon will not ingest new ledgers.
- Add new command
horizon db detect-gaps
, which detects ingestion gaps in the database. The command prints out thedb reingest
commands to run in order to fill the gaps found (3672). - Performance improvement: Captive Core now reuses bucket files whenever it finds existing ones in the corresponding
--captive-core-storage-path
(introduced in v2.1.0 rather than generating a one-time temporary sub-directory (3670). This feature requires Stellar-Core version 17.1 or later. - Horizon now monitors the Stellar Core binary on disk (pointed to by
--stellar-core-binary-path
/STELLAR_CORE_BINARY_PATH
) and restarts its Captive Core subprocess if it detects changes (i.e a more recent file timestamp for the Stellar Core binary) (3687). POST /transactions
return503 Service Unavailable
instead of504 Gateway Timeout
if connected Stellar-Core is out of sync (3653).- Add protocol version metrics:
horizon_ingest_max_supported_protocol_version
,horizon_ingest_captive_stellar_core_supported_protocol_version
,horizon_stellar_core_supported_protocol_version
(3634). - Fixed crash in
horizon ingest verify-range
command (3682). - Handle replica conflict errors gracefully (3674).
- Fix data race in request parameters handling (3690).
- Fix bug where the configuration for
CAPTIVE_CORE_LOG_PATH
,CAPTIVE_CORE_PEER_PORT
, andCAPTIVE_CORE_HTTP_PORT
were ignored if they were configured via environment variables instead of command line arguments. (3702). - Error when setting
BUCKET_DIR_PATH
through--captive-core-config-path
(3707).
Horizon v2.4.1
Upgrading to this version from <= v2.1.1 will trigger a state rebuild. During this process (which can take up to 20 minutes), Horizon will not ingest new ledgers.
Code Changes
- Fix bug in
horizon db reingest range
command, which would throw a duplicate entry conflict error from the DB. (3661). - Fix bug in DB metrics preventing Horizon from starting when read-only replica middleware is enabled. (3668).
- Fix bug in the value of
route
in the logs for rate-limited requests (previously it was set toundefined
). (3658).
horizonclient v7.1.0 & txnbuild v7.1.0
horizonclient
- Added transaction and operation result codes to the horizonclient.Error string for easy glancing at string only errors for underlying cause.
- Fix bug in the transaction submission where requests with large transaction payloads fail with an HTTP 414 URI Too Long error (#3643).
txnbuild
New features
- Add
SequenceNumber
function toTransaction
. - Add
AddSignatureDecorated
function toTransaction
.
Bug Fix
BaseFee
inTransactionParams
when callingNewTransaction
is allowed to be zero because the fee can be paid by wrapping aTransaction
in aFeeBumpTransaction
. (#3622)
Horizon v2.4.0
Upgrading to this version from <= v2.1.1 will trigger a state rebuild. During this process (which can take up to 20 minutes), Horizon will not ingest new ledgers.
DB State Migration
- This release comes with a small DB schema change (new multiplexed-account-related columns are incorporated). It should not take more than five minutes to run due to new columns being NULL-able.
Deprecations
- Deprecate
--captive-core-config-append-path
in favor of--captive-core-config-path
. The difference between the two flags is that--captive-core-config-path
will validate the configuration file to reject any fields which are not supported by captive core (3629).
New features
-
Add more in-depth Prometheus metrics (count & duration) for db queries. (3597, 3605)
-
HTTP request logs will now print the Origin header if Referer is not set. (3599)
-
Add Multiplexed Account details to API responses (additional
_muxed
and_muxed_id
optional fields following what's described in SEP 23):- Transactions:
account_muxed
,account_muxed_id
,fee_account
andfee_account_muxed
. - Operations:
source_account_muxed
,source_account_muxed_id
and additional fields depending on the operation (e.g.from_muxed
,from_muxed_id
,to_muxed
andto_muxed_id
for Payment operations) - Effects:
account_muxed
,account_muxed_id
and additional fields depending on the effect (e.g.seller_muxed
andseller_muxed_id
for the Trade effect).
- Transactions:
Code Changes
stellar-ingest v2.0.0
This release of the ingest
package is related to the release of Horizon v2.3.0 and introduces some breaking changes for those building their own tools. Refer to stellar-ingest-v1.0.0 for more on this package.
Breaking Changes
-
Many APIs now require a
context.Context
parameter, allowing you to interact with the backends and control calls in a more finely-controlled manner. This includes the readers (ChangeReader
et al.) as well as the backends themselves (CaptiveStellarCore
et al.). -
GetLedger()
always blocks now, even for anUnboundedRange
. -
The
CaptiveCoreBackend
now requires an all-inclusiveCaptiveCoreToml
object to configure Captive Core rather than an assortment of individual parameters. This object can be built from a TOML file (seeNewCaptiveCoreTomlFromFile
) or from parameters (seeNewCaptiveCoreToml
) as was done before. -
LedgerTransaction.Meta
has been renamed toUnsafeMeta
to highlight that users should be careful when interacting with it. -
Remote Captive Core no longer includes the
present
field in the ledger response JSON.
New Features
NewLedgerChangeReaderFromLedgerCloseMeta
andNewLedgerTransactionReaderFromLedgerCloseMeta
are new ways to construct readers from a particular single ledger.
Other Changes
-
The remote Captive Core client timeout has doubled.
-
Captive Core now creates a temporary directory (
captive-core-...
) in the specified storage path (current directory by default) that it cleans it up on shutdown rather than in the OS's temp directory.
Horizon v2.3.0
Upgrading to this version from <= v2.1.1 will trigger a state rebuild. During this process (which can take up to 20 minutes), Horizon will not ingest new ledgers.
New features
- Introduces a flag (
--ro-database-url
/RO_DATABASE_URL
) which allows setting a connection to a read-replica database. This flag makes Horizon take into account data propagation lag to the replica instance, adding retries if the data is out of sync (3574).
Code changes
-
Improved test suite coverage and stability (3560, 3562, 3551, and 3547).
-
Improved session handling and timeouts (3576, 3545, and 3567).
-
Improved stability of configuring Captive Core, intelligently merging parameters from the possible sources. Specifically, it will now prefer either the command-line parameter (e.g.
--captive-core-peer-port
or its env-var equivalent) or the user-supplied append file (--captive-core-append-path
) over Horizon's internal defaults. However, if a value is set in both the append file and at the command-line, an error will be thrown unless both values are equal (3558).
horizonclient v7.0.0 & txnbuild v7.0.0
Breaking changes
AllowTrustOpAsset
was renamed toAssetCode
,{Must}NewAllowTrustAsset
was renamed to{Must}NewAssetCodeFromString
.- Some methods from the
Operation
interface (BuildXDR()
,FromXDR()
andValidate()
) now take an additionalbool
parameter (withMuxedAccounts
)
to indicate whether SEP23 M-strkeys should be enabled.
New features
- Add support for Stellar Protocol 17 (CAP35):
Clawback
,ClawbackClaimableBalance
andSetTrustlineFlags
operations. - Add opt-in support for SEP23 M-strkeys for
MuxedAccount
s:- Some methods from the
Operation
interface (BuildXDR()
,FromXDR()
andValidate()
) now take an additionalbool
parameter (withMuxedAccounts
) - The parameters from
NewFeeBumpTransaction()
andNewTransaction()
now include a new field (EnableMuxedAccounts
) to enable M-strekeys. TransactionFromXDR()
now allows passing aTransactionFromXDROptionEnableMuxedAccounts
option, to enable M-strkey parsing.
- Some methods from the
Horizon 2.2.0
Upgrading to this version will trigger state rebuild. During this process (which can take up to 20 minutes) it will not ingest new ledgers.
Horizon v2.1.1
- When ingesting a backlog of ledgers, Horizon sometimes consumes ledgers faster than the rate at which Captive Core emits them. Previously this scenario caused failures in the ingestion system. That is now fixed in (3531).