all: Merge Horizon's Protocol 19 implementation into master #4340
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…#4279) * Add Protocol 19 XDR: raw and generated * Update codebase to use new XDR for predicates/timebounds * Add stringification method for Preconditions * Add encode/decode helper for CAP-40 signed payloads * Add Horizon DB migration: signers can be longer now * Disable generating the V3 extension on accounts
horizon: Merge master into horizon-protocol-19 branch
… that they are implemented. (#4304)
Adds support for new CAP-21 preconditions with a simple, but breaking API change: TransactionParams.Timebounds -> TransactionParams.Preconditions.TimeBounds You can now pass a lot more preconditions to a Transaction (including timebounds), and these are managed by the new Preconditions object. All of the XDR abstractions are hidden away behind this object.
* Add cap-21 transaction preconditions * Replace xdr.TransactionEnvelope.TimeBounds -> .Preconditions function * Rename Signers -> ExtraSigners for more consistent naming * Store the new precondition fields in the DB * Render the new precondition fields in the resourceadapter * ./gogenerate.sh * use a pointer so omitempty works * more consistent naming * Keep Timebounds helper * PR feedback * tidy transaction precondition helpers * typo fixes * remove dead param * use bigint so we have enough space for a uint32 * use text instead of varchar, to avoid future migrations * Updating scenario sqls * need to load the preconditions from the db * Temporary passing data for v2 preconditions transaction insertion test * Update xdr/transaction_envelope_test.go Co-authored-by: George <Shaptic@users.noreply.github.com> * Update services/horizon/internal/db2/history/transaction_ledger_bounds.go Co-authored-by: George <Shaptic@users.noreply.github.com> * PR feedback Co-authored-by: George <Shaptic@users.noreply.github.com>
…s`. (#4307) * Timebounds -> TimeBounds, Ledgerbounds -> LedgerBounds * Duration -> int64, SignerKey -> string
* Update XDR to latest from sisuresh/stellar-core#cap21-40-2 * Update codebase to make cb predicates use Int64s again
horizon: Merge master into horizon-protocol-19 branch
Co-authored-by: Shawn Reuland <shawn@stellar.org>
Added additional round trip verification by re-querying preconditions on tx after submission, per pr feedback
services/horizon/integration: Added more integration tests for coverage of preconditions on transactions
…years (#4337) * Merge Protocol 19 migrations into a single file * Actually generate V3 account extensions * Change accounts.sequence_time to be bigint over timestamp: This is necessary because PostgreSQL puts "reasonable" limitations on how dates can be represented. Because the state verifier test will generate random int64s for the V3 account extension field introduced in CAP-21, this will blow up on inserting into the DB with errors like: pq: date/time field value out of range: "120911623444-02-01 21:35:20Z" because PostgreSQL only allows years up to 5874897 (https://stackoverflow.com/a/36446977). Technically, since this field is not user-controlled and comes directly from Stellar Core, we would not see this in practice. However, it's a more durable fix to stop the extra layer of "interpretation" of this value and just treat it like it is: a 64-bit integer that happens to represent a UNIX timestamp.
…nt` to string (#4339) * `minSeqAge` can be unsigned in the XDR * Update codebase to conform to new data type: null.Int -> null.String * Fix time-based tests to be tz-agnostic + work w/ uint64
sreuland
reviewed
Apr 18, 2022
| @@ -0,0 +1,28 @@ | |||
| -- +migrate Up | |||
There was a problem hiding this comment.
do any of these schema changes require extra notes on CHANGELOG for state rebuild or re-ingestion requirements? I noticed the services/horizon/CHANGELOG.md isn't updated for P19 yet, that was gonna be drated up on the release branch instead?
sreuland
approved these changes
Apr 18, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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, orallordocif the changes are broad or impact manypackages.
Thoroughness
.mdfiles, etc... affected by this change). Take a look in the
docsfolder 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
This is a final merge of all of Horizon's Protocol 19 changes into the mainline.
Why
See #4261 for a comprehensive list of features and related PRs for this merge.
Known limitations
n/a