Protocol 27 (CAP-0071) ingestion#186
Conversation
- Pin go-stellar-sdk to the CAP-71/CAP-83 XDR build. - Bump MaxSupportedProtocolVersion to 27. - Implement GetLedgerRaw on fakeLedgerBackend (added to the SDK LedgerBackend interface).
go-stellar-sdk@130456cc9b69 is regenerated from stellar-xdr@68fa1ac (post- stellar/stellar-xdr#303 ungate of CAP_0071) with XDR_FEATURES cleared, so the bind no longer carries the CAP-0083 STELLAR_VALUE_EMPTY_TX_SET path — matching the p27 release scope (CAP-0071 only; CAP-0083 deferred). The SDK bump also transitively picks up stellar/go-xdr#32, which raises DecodeDefaultMaxDepth 250 → 1500, so the CAP-71 240-deep delegate fixture (test-lcms/InvokeHostFunctionTests/a7a45d93c64cf3d9.xdr) now ingests without ErrMaxDecodingDepth. The HerderTests fixture (network_externalizes_empty-tx-set_on_missing_value) no longer decodes under CAP-71-only XDR (StellarValueType 2 is gone) and is removed.
sisuresh
changed the title
|
Update (CAP-71-only for p27 release) P27 ships with CAP-0071 only — CAP-0083 has been deferred. Pushed
Branch name still says Note: the 240-deep CAP-71 delegate fixture |
Core 27 reworked the apply-load configuration: the sampled load parameters (APPLY_LOAD_INSTRUCTIONS, APPLY_LOAD_TX_SIZE_BYTES, APPLY_LOAD_NUM_RW_ENTRIES, etc.) were removed in favor of an APPLY_LOAD_MODE selector, and the apply-load command now force overrides NETWORK_PASSPHRASE to "Apply Load" and runs at the core's current ledger protocol version. - Add testdata/apply-load-v27.cfg based on core 27's docs/apply-load-for-meta.cfg - Select the default config based on the core binary's major version - Assert ledger protocol version against the core binary's reported protocol version instead of the max supported protocol env var
- Add load-test-ledgers-v27.xdr.zstd / load-test-fixtures-v27.xdr.zstd, generated via TestGenerateLedgers using the same stellar-core build CI pins (27.0.0-3288.7696c069d, buildtests). Fixes TestLoadTestLedgerBackendWithoutMerge, which looks up the fixture for MaxSupportedProtocolVersion (now 27). - Core 27's apply-load command force-overrides the network passphrase to "Apply Load", so the load tests now select the fixture passphrase by protocol version. - Restore the 240-deep CAP-71 delegate-tree LCM fixture (InvokeHostFunctionTests/a7a45d93c64cf3d9.xdr, still referenced by index.json): it was dropped while go-xdr's max decoding depth was 250, and ingests cleanly again with stellar/go-xdr#32 (depth 1500).
Shaptic
left a comment
Shaptic
left a comment
There was a problem hiding this comment.
LGTM, needs a little more cleanup but I can do that separately 👍
There was a problem hiding this comment.
These weren't here before, why here now? We only had the frozen and invoke ones.
There was a problem hiding this comment.
Missed this earlier. I just added all of the ones generated on the core side.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3b9867715e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| PROTOCOL_26_CORE_DOCKER_IMG: stellar/stellar-core:27.0.0-3288.7696c069d.jammy | ||
| PROTOCOL_26_CORE_DEBIAN_PKG_VERSION: 27.0.0-3288.7696c069d.jammy~buildtests |
There was a problem hiding this comment.
In the inspected horizon.yml workflow, the matrix still only sets HORIZON_INTEGRATION_TESTS_CORE_MAX_SUPPORTED_PROTOCOL to 25 or 26, and internal/test/integration.NewTest caps the test protocol to that env value when it is lower than ingest.MaxSupportedProtocolVersion. As a result these 27.0 core images are still exercised as protocol-26 jobs, so the new v27 fixtures and protocol-27 ingestion path are not covered by CI; add a protocol-version 27 matrix entry with corresponding PROTOCOL_27_* env vars instead of replacing the protocol-26 image.
Useful? React with 👍 / 👎.
| gopkg.in/yaml.v3 v3.0.1 // indirect | ||
| ) | ||
|
|
||
| replace github.com/stellar/go-stellar-sdk => github.com/sisuresh/go v0.0.0-20260603235145-a8d5b3066361 |
There was a problem hiding this comment.
This replace makes every build resolve github.com/stellar/go-stellar-sdk to github.com/sisuresh/go, so releases and CI now depend on a personal fork rather than the official Stellar module. In production builds this can silently diverge from upstream fixes or fail if the fork is removed or rewritten; please depend on an official Stellar module version or vendor an upstream commit before enabling protocol 27.
Useful? React with 👍 / 👎.
* Protocol 27 ingestion (#186) * Protocol 27 (CAP-0071 + CAP-0083) ingestion support - Pin go-stellar-sdk to the CAP-71/CAP-83 XDR build. - Bump MaxSupportedProtocolVersion to 27. - Implement GetLedgerRaw on fakeLedgerBackend (added to the SDK LedgerBackend interface). * update core test lcm * add GetLedgerRaw * update * Bump go-stellar-sdk to CAP-71-only XDR; drop CAP-83 fixture go-stellar-sdk@130456cc9b69 is regenerated from stellar-xdr@68fa1ac (post- stellar/stellar-xdr#303 ungate of CAP_0071) with XDR_FEATURES cleared, so the bind no longer carries the CAP-0083 STELLAR_VALUE_EMPTY_TX_SET path — matching the p27 release scope (CAP-0071 only; CAP-0083 deferred). The SDK bump also transitively picks up stellar/go-xdr#32, which raises DecodeDefaultMaxDepth 250 → 1500, so the CAP-71 240-deep delegate fixture (test-lcms/InvokeHostFunctionTests/a7a45d93c64cf3d9.xdr) now ingests without ErrMaxDecodingDepth. The HerderTests fixture (network_externalizes_empty-tx-set_on_missing_value) no longer decodes under CAP-71-only XDR (StellarValueType 2 is gone) and is removed. * Bump go-stellar-sdk to latest CAP-71-only build (a8d5b306) * Bump protocol 26 core version to 27.0.0-3288.7696c069d * Support core 27 apply-load config in TestGenerateLedgers Core 27 reworked the apply-load configuration: the sampled load parameters (APPLY_LOAD_INSTRUCTIONS, APPLY_LOAD_TX_SIZE_BYTES, APPLY_LOAD_NUM_RW_ENTRIES, etc.) were removed in favor of an APPLY_LOAD_MODE selector, and the apply-load command now force overrides NETWORK_PASSPHRASE to "Apply Load" and runs at the core's current ledger protocol version. - Add testdata/apply-load-v27.cfg based on core 27's docs/apply-load-for-meta.cfg - Select the default config based on the core binary's major version - Assert ledger protocol version against the core binary's reported protocol version instead of the max supported protocol env var * Add v27 load-test fixtures; restore deep-delegate LCM fixture - Add load-test-ledgers-v27.xdr.zstd / load-test-fixtures-v27.xdr.zstd, generated via TestGenerateLedgers using the same stellar-core build CI pins (27.0.0-3288.7696c069d, buildtests). Fixes TestLoadTestLedgerBackendWithoutMerge, which looks up the fixture for MaxSupportedProtocolVersion (now 27). - Core 27's apply-load command force-overrides the network passphrase to "Apply Load", so the load tests now select the fixture passphrase by protocol version. - Restore the 240-deep CAP-71 delegate-tree LCM fixture (InvokeHostFunctionTests/a7a45d93c64cf3d9.xdr, still referenced by index.json): it was dropped while go-xdr's max decoding depth was 250, and ingests cleanly again with stellar/go-xdr#32 (depth 1500). * Bump integration tests to use Protocol 27 (#189) * Bump go-stellar-sdk to v0.6.0 (#191) * Bump verify-range stellar-core to Protocol 27 noble build (#192) --------- Co-authored-by: Siddharth Suresh <siddharth@stellar.org> Co-authored-by: urvisavla <urvi.savla@stellar.org>
2 participants
This branch was used to stand up an end-to-end Stellar Quickstart test of CAP-0083 ("Allow validators to vote to skip the current ledger", stellar-core PR #5209), together with CAP-0071. It carries the downstream changes required so a custom quickstart image (CAP-83
stellar-core+ this component) runs at protocol 27 and handles CAP-83 skip ledgers (STELLAR_VALUE_EMPTY_TX_SET).Rebased on
main; opened againstprotocol-next.stellar-horizon
go-stellar-sdkto the CAP-71/CAP-83 Go XDR build.MaxSupportedProtocolVersionto 27.GetLedgerRawonfakeLedgerBackend(added to the SDKLedgerBackendinterface).