Bump integration tests to use Protocol 27 - #189
Conversation
Shaptic
commented
Jun 8, 2026
Shaptic
commented
- Replace pNext fork with official SDK git ref
- Bump integration test constants
![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
https://github.com/stellar/stellar-horizon/blob/36cc53a15e5d814ef030b0a65b8807934ceece01/internal/integration/testdata/unlimited-config-v25.xdr#L1
When the integration suite is run with HORIZON_INTEGRATION_TESTS_CORE_MAX_SUPPORTED_PROTOCOL=25, the load-test guards in internal/integration/ingestion_load_test.go and generate_ledgers_test.go still allow the tests to run, and upgradeLimits still reads testdata/unlimited-config-v%d.xdr. Renaming this fixture to v27 and deleting the v25 ledgers/fixtures means those Protocol 25 runs now fail with missing testdata instead of being skipped; either keep the v25 files or change the guards/docs to require Protocol 26+.
ℹ️ 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_27_CORE_DOCKER_IMG: stellar/stellar-core:27.0.0-3288.7696c069d.noble | ||
| PROTOCOL_27_CORE_DEBIAN_PKG_VERSION: 27.0.0-3288.7696c069d.noble | ||
| PROTOCOL_27_STELLAR_RPC_DOCKER_IMG: stellar/stellar-rpc:26.0.0 |
There was a problem hiding this comment.
These newly added Protocol 27 core/RPC/package values are used to decide what runtime the integration tests exercise, but the Calculate the source hash step below still interpolates the removed PROTOCOL_25_* values and only the Protocol 26 core image. If the Protocol 27 core package or RPC image is bumped without changing Go/internal sources, actions/cache/restore can reuse an old successful key for the Protocol 27 matrix entry and skip go test, leaving the new runtime untested.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4ca2b724be
ℹ️ 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:26.0.0-3089.8e43a2d3b.noble~buildtests | ||
| PROTOCOL_26_CORE_DEBIAN_PKG_VERSION: 26.0.0-3089.8e43a2d3b.noble~buildtests | ||
| PROTOCOL_26_STELLAR_RPC_DOCKER_IMG: stellar/stellar-rpc:26.0.0 | ||
| PROTOCOL_27_CORE_DOCKER_IMG: stellar/stellar-core:27.0.0-3288.7696c069d.noble~buildtests |
There was a problem hiding this comment.
In the Pull and set Stellar Core image step, this value is passed directly to docker pull; for both protocol 26 and 27 the tag now contains ~buildtests. Docker's tag documentation limits tag characters to letters, digits, underscores, periods, and hyphens, so these references are invalid and the integration workflow will fail before running tests for every protocol-version matrix entry.
Useful? React with 👍 / 👎.
| id: calculate_source_hash | ||
| run: | | ||
| combined_hash=$(echo "horizon-hash-${{ hashFiles('./') }}-${{ hashFiles('./docker/**') }}-${{ hashFiles('./internal/**') }}-protocol-${{ matrix.protocol-version }}-${{ env.PROTOCOL_25_CORE_DOCKER_IMG }}-${{ env.PROTOCOL_25_STELLAR_RPC_DOCKER_IMG }}-${{ env.PROTOCOL_25_CORE_DEBIAN_PKG_VERSION }}-${{ env.PROTOCOL_26_CORE_DOCKER_IMG }}-${{ env.PREFIX }}" | sha256sum | cut -d ' ' -f 1) | ||
| combined_hash=$(echo "horizon-hash-${{ hashFiles('./') }}-${{ hashFiles('./docker/**') }}-${{ hashFiles('./internal/**') }}-protocol-${{ matrix.protocol-version }}-${{ env.PROTOCOL_27_CORE_DOCKER_IMG }}-${{ env.PROTOCOL_27_STELLAR_RPC_DOCKER_IMG }}-${{ env.PROTOCOL_27_CORE_DEBIAN_PKG_VERSION }}-${{ env.PROTOCOL_26_CORE_DOCKER_IMG }}-${{ env.PREFIX }}" | sha256sum | cut -d ' ' -f 1) |
There was a problem hiding this comment.
The current key includes the Protocol 27 values but still omits PROTOCOL_26_CORE_DEBIAN_PKG_VERSION and PROTOCOL_26_STELLAR_RPC_DOCKER_IMG, even though the protocol-26 matrix uses those variables in the Install core and Pull and set Stellar RPC image steps. If either Protocol 26 runtime changes without source changes, actions/cache/restore can hit a key from the previous runtime and skip go test, leaving that updated Protocol 26 environment untested.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2d48d22b4d
ℹ️ 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_27_CORE_DOCKER_IMG: stellar/stellar-core:27.0.0-3288.7696c069d.noble | ||
| PROTOCOL_27_CORE_DEBIAN_PKG_VERSION: 27.0.0-3288.7696c069d.noble~buildtests |
There was a problem hiding this comment.
In the protocol-version: 27 matrix, the workflow passes these exact values to docker pull and apt-get install; the install step below still documents that the 27.0.0 core build is only published for jammy and adds the jammy repo for that reason. Pointing both Protocol 27 core variables at the noble build makes the Protocol 27 jobs fail before running integration tests unless a matching noble image/package is actually published, so these should use the jammy build or a verified published noble build.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0fac9fa0b9
ℹ️ 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_27_CORE_DOCKER_IMG: stellar/stellar-core:27.0.0-3288.7696c069d.jammy | ||
| PROTOCOL_27_CORE_DEBIAN_PKG_VERSION: 27.0.0-3288.7696c069d.jammy~buildtests |
There was a problem hiding this comment.
For the protocol-version: 27 matrix entry, this value is passed directly to docker pull before any tests run, and the matching package version on the next line is installed exactly by apt-get. Fresh check: Docker Hub currently advertises the Protocol 27 stellar/stellar-core tag as 27.0.1-3306.02fa3131b.jammy, while the exact 27.0.0-3288.7696c069d.jammy tag has no published result, so the Protocol 27 jobs will fail during setup instead of exercising the new runtime. This is fresh evidence beyond the earlier comment: the code now uses jammy, but it still pins an unavailable/stale build.
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 <[email protected]> Co-authored-by: urvisavla <[email protected]>
The P28 integration leg reads testdata/unlimited-config-v28.xdr in upgradeLimits() (internal/test/integration/integration.go:787); it was missed in the P28 bump, so every P28 test going through StartHorizon setup failed with "open testdata/unlimited-config-v28.xdr: no such file or directory". CAP-0083 adds no Soroban config settings, so the v28 ConfigUpgradeSet is byte-identical to v27 under the P28 go-stellar-sdk pin (v26 and v27 are already byte-identical). The protocol matrix is [27, 28], so v26 is now unreferenced; drop it to keep testdata aligned with the matrix, matching the rolling-window precedent from stellar#171/stellar#189.
* Re-pin go-stellar-sdk to the CAP-0083 XDR regeneration and bump MaxSupportedProtocolVersion to 28. * Add v28 load-test fixtures * CI: run integration tests against Protocol 28 Switch the integration matrix to protocol-version [27, 28]. P28 uses the vnext (next-protocol-enabled) core build 27.0.1-3348.ff61f2e6d. The P28 stellar-rpc image is left as a commented placeholder until stellar-rpc#789 publishes one, so that leg stays amber rather than testing against a P27 RPC. Repoint the cache source hash to the P28 (latest) + P27 (previous) images. * CI: build a P28 stellar-rpc image from stellar-rpc#789 instead of failing the leg The P28 matrix leg had no PROTOCOL_28_STELLAR_RPC_DOCKER_IMG (no published P28-capable stellar-rpc image exists; stellar-rpc#789 is still a draft over protocol-next and the repo only publishes images from main/release/**). The "Pull and set Stellar RPC image" step ran `docker pull ""` -> invalid reference format -> the P28 legs went red and fail-fast cancelled the P27 legs. Leaving the image empty was not a safe "amber": the compose default (stellar/stellar-rpc) is a P27 RPC, so the soroban suites would have run against the wrong RPC. - Guard the RPC pull step so a missing prebuilt image is a no-op. - Build a genuine P28 stellar-rpc image in-CI from stellar-rpc#789 source, fetched by pinned SHA via refs/pull/789/head (there is no p28-cap-0083 branch on stellar/stellar-rpc; the head lives on a fork), plus the pinned P28 captive-core deb, and run all six EnableStellarRPC suites (sac, invokehostfunction, extend_footprint_ttl, txsub, txsub_async, transaction) against it on the P28 leg. - If that build is unavailable, skip those suites loudly (tracked to stellar-rpc#789) rather than silently falling back to a P27 RPC. * CI: drop P28 stellar-rpc from-source build; reuse the P27 RPC image CAP-0083 is consensus-layer (skip ledgers); the RPC layer is unaffected, so the P27 stellar-rpc image is functionally adequate for the P28 integration leg. Reverts the from-source-build pipeline added in a9fe4d7 in favor of the simple two-line "use previous protocol's image + TODO". Drops: - PROTOCOL_28_STELLAR_RPC_PR_SHA env var - "Build P28 stellar-rpc image from stellar-rpc#789" step - empty-IMG handling in "Pull and set Stellar RPC image" - PR_SHA reference in the source-hash key Restores the original "Pull and set Stellar RPC image" step. When a real P28 stellar-rpc image is published, replace the PROTOCOL_28_STELLAR_RPC_DOCKER_IMG value with the new tag and drop the TODO. * Roll integration test fixture window to {v27, v28} The P28 integration leg reads testdata/unlimited-config-v28.xdr in upgradeLimits() (internal/test/integration/integration.go:787); it was missed in the P28 bump, so every P28 test going through StartHorizon setup failed with "open testdata/unlimited-config-v28.xdr: no such file or directory". CAP-0083 adds no Soroban config settings, so the v28 ConfigUpgradeSet is byte-identical to v27 under the P28 go-stellar-sdk pin (v26 and v27 are already byte-identical). The protocol matrix is [27, 28], so v26 is now unreferenced; drop it to keep testdata aligned with the matrix, matching the rolling-window precedent from #171/#189.
3 participants
