Protocol 28 (CAP-0083)#789
Conversation
Re-pin go-stellar-sdk to the CAP-0083 XDR regeneration (SPIKE) and enable the cap_0083 feature on stellar-xdr (=27.0.0, already carries the generated types) so the EmptyTxSet StellarValueType variant is compiled in. rs-soroban-env unchanged; no version bump.
The gomoddirectives linter (enabled via `default: all`) rejects the `replace github.com/stellar/go-stellar-sdk => github.com/sisuresh/go` directive added for the CAP-0083 SPIKE, failing the Go workflow and the `complete` gate. Add it to gomoddirectives' replace-allow-list. Revert once go-stellar-sdk#5952 merges and the replace is dropped for a tagged release.
Matches the reviewed head of stellar/go-stellar-sdk#5952.
![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: dbd841c89b
ℹ️ 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".
| gopkg.in/yaml.v3 v3.0.1 // indirect | ||
| ) | ||
|
|
||
| replace github.com/stellar/go-stellar-sdk => github.com/sisuresh/go v0.0.0-20260616005412-4615d5e81367 |
There was a problem hiding this comment.
With this replace, the dependency-sanity-checker workflow still runs scripts/check-dependencies.bash, which asks go list -m -f '{{.Version}}' github.com/stellar/go-stellar-sdk and then fetches XDR metadata from github.com/stellar/go-stellar-sdk/${GO_XDR_REVISION}. I checked the module output with this change and Go reports the original required version v0.6.0 plus the replacement path/version separately, so the checker ignores the CAP-0083 fork and compares against the old upstream SDK data. Please make the script use .Replace.Path/.Replace.Version when present, otherwise this sanity check can pass or fail on the wrong Go XDR revision.
Useful? React with 👍 / 👎.
…ception go-stellar-sdk#5952 (Protocol 28 / CAP-0083) merged into protocol-next at 26fec7c0e891cd88227494e212ecf712e873f039. Drop the sisuresh fork replace directive and pin the require to the upstream merged commit, superseding the review-head pin (4615d5e81367a2e7d42a87c856226d3bc36a3554). The two commits share the same git tree, so no XDR/content change is expected; build and `go mod tidy` verified. Also remove the SPIKE-only gomoddirectives.replace-allow-list entry for github.com/stellar/go-stellar-sdk from .golangci.yml — it existed solely to permit the now-removed fork replace and its own comment said to delete it once #5952 merged.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
rs-stellar-xdr moved xdr/curr-version to top-level xdr-version in v27, but the git-revision branch of check-dependencies.bash still curls the old path and 404s for any current git pin. Read xdr-version first and fall back to xdr/curr-version for older layouts, with the || moved outside the command substitution so a --fail-with-body 404 body can't be concatenated into the captured revision.
Rolling-window the supported-protocol matrix for the protocol-next
release branch: keep the previous (P27) leg as a regression guard and
add a P28 leg that exercises CAP-0083 against the vnext core build.
Drop the P26 leg per the {curr-1, curr, curr+1} window convention.
P28 uses the vnext core build pinned to 3312 (02fa3131b), which predates
a stellar-core init-order change that breaks captive-core bootstrap on
a fresh storage dir. Bump once that's fixed upstream.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5dca26a9a
ℹ️ 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".
| # xdr2json. It was enabled by default in stellar-xdr v26 but is opt-in in v27. | ||
| features = ["serde", "type_enum"] | ||
| # `cap_0083` gates the Protocol 28 EmptyTxSet StellarValueType variant. | ||
| features = ["serde", "type_enum", "cap_0083"] |
There was a problem hiding this comment.
Adding cap_0083 here leaves the Rust crate at stellar-xdr =27.0.0, whose recorded xdr-version is still 68fa1ac..., while the new Go SDK records the CAP-0083 XDR commit 8521b97.... The dependency-sanity-checker runs scripts/check-dependencies.bash and compares those exact Stellar XDR revisions, so this PR fails that workflow before tests run and the Rust/Go sides are no longer pinned to the same generated XDR metadata. Please pin stellar-xdr to a release or git rev generated from the CAP-0083 commit, or update the checker if this feature build is intentionally equivalent.
Useful? React with 👍 / 👎.
| name: Integration tests (P28) | ||
| uses: ./.github/workflows/integration-tests.yml | ||
| with: | ||
| protocol_version: '28' |
There was a problem hiding this comment.
When this new job runs with protocol_version: '28', the reusable workflow exports that value as STELLAR_RPC_INTEGRATION_TESTS_CORE_MAX_SUPPORTED_PROTOCOL; NewTest then defaults to protocol 28 and upgradeLimits() reads unlimited.p28.xdr. The embedded upgrade directory only contains p26/p27 limit files, so default integration tests in the P28 leg fail during startup before exercising CAP-0083. Add p28 fixtures or skip the limit-upgrade step for this consensus-only protocol.
Useful? React with 👍 / 👎.
CAP-0083 is consensus-layer (skip-ledgers via STELLAR_VALUE_EMPTY_TX_SET) and doesn't change the soroban ConfigSettings. The P28 `unlimited` and `testnet` upgrade payloads are byte-identical to P27 — just provide them under the protocol-suffixed filenames `upgradeLimitsWithFile()` expects.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fd44198b50
ℹ️ 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".
| name: Integration tests (P28) | ||
| uses: ./.github/workflows/integration-tests.yml | ||
| with: | ||
| protocol_version: '28' |
There was a problem hiding this comment.
When this job sets STELLAR_RPC_INTEGRATION_TESTS_CORE_MAX_SUPPORTED_PROTOCOL=28, integration tests create protocol-28 ledgers and the RPC simulation/submission paths pass that ledger protocol into preflight. The Rust FFI currently only accepts proto <= prev::PROTOCOL or proto == curr::PROTOCOL, and curr is still soroban-env-host 27.0.0, so any Soroban preflight on P28 returns unsupported protocol version: 28. Please either treat consensus-only P28 as the current host protocol or bump the host before enabling the P28 leg.
Useful? React with 👍 / 👎.
| protocol_version: '28' | ||
| # Protocol 28 (CAP-0083) runs against the vnext (next-protocol-enabled) | ||
| # core build. Matches the pin used by stellar-horizon's P28 leg. | ||
| core_deb_version: '27.0.1-3348.ff61f2e6d.jammy~vnext~buildtests' |
There was a problem hiding this comment.
The dependency sanity checker parses this packaged-core job as (28, ff61f2e6d) and then fetches stellar-core/ff61f2e6d/src/rust/src/dep-trees/p28-expect.txt; that core commit only has dep-tree expectations through p27-expect.txt, and curl --help all documents --fail-with-body as failing on HTTP errors, so the required dependency checker will fail as soon as the earlier Rust/Go XDR mismatch is fixed. For this consensus-only P28 build, map the checker to the p27 host tree or pin a core commit that includes a p28 expectation.
Useful? React with 👍 / 👎.
The P27 leg uses the plain release deb (`...jammy`), but the P28 leg I added was using `...jammy~vnext~buildtests`. The buildtests variant has assertions enabled and is meaningfully slower under integration test load — likely contributing to the backfill tests missing their 60s polling deadlines. Switch to the plain vnext deb (`...jammy~vnext`) to match the P27 leg's variant choice. Docker tag must still come from `unsafe-stellar-core` (vnext tags aren't published to the plain `stellar-core` repo).
CAP-0083 is consensus-layer (skip ledgers via STELLAR_VALUE_EMPTY_TX_SET) and doesn't change any soroban host behavior, so we don't bump soroban-env-host's version pin. But the host still has a hardcoded "supported protocol versions" table, and without the `next` feature flag it caps that table at protocol 27. That's why every preflight call against a P28 network was failing with "unsupported protocol version: 28" — the host built without `next` literally doesn't believe P28 exists. Enabling the feature on the `-curr` host pin declares P28 as supported without changing any runtime behavior.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 93c9c498ba
ℹ️ 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".
| # supported protocol). Without it, preflight rejects every P28 request | ||
| # with "unsupported protocol version: 28" even when the underlying | ||
| # CAP (CAP-0083) introduces no host-layer changes. | ||
| features = ["next"] |
There was a problem hiding this comment.
With this feature enabled, soroban_env_host::meta::INTERFACE_VERSION.protocol becomes 28, but the preflight dispatcher still only routes proto <= prev::PROTOCOL or proto == curr::PROTOCOL. Since prev::PROTOCOL is 26, any protocol-27 ledger now falls through to unsupported protocol version: 27; the P27 integration job kept in .github/workflows/stellar-rpc.yml and any P27 simulation/submission paths will fail. This is fresh evidence beyond the earlier P28 unsupported issue: the new next feature flips the current host protocol to 28 without preserving the 27 mapping.
Useful? React with 👍 / 👎.
Shift the soroban-env-host window for protocol 28: - -prev: crates.io 26.1.2 → crates.io =27.0.0 - -curr: crates.io 27.0.0 (no features) → upstream git rev 883fd56374f, features=["next"], which advances curr::PROTOCOL to 28. Using a git rev (instead of crates.io 27.0.0 + 'next') is required because cargo refuses two aliases of the same crate+version. With this shape, the preflight dispatcher gets the correct routing: P<=27 → prev (handles P25/P26/P27) P==28 → curr which preserves the kept P27 integration job after the codex bot caught that the previous one-sided 'next' bump on -curr alone would have flipped curr::PROTOCOL to 28 and orphaned every P27 ledger. Also propagate the -prev API shift: soroban-env-host 27.0.0 reshapes RecordingInvocationAuthMode::Recording from (bool) to a params struct, so prev::recording_auth_mode is now built via ::recording(disable_non_root_auth, false) — same constructor curr::recording_auth_mode already uses. Bump the git rev as rs-soroban-env evolves on its protocol-next track.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c48e12d7a
ℹ️ 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".
| [workspace.dependencies.soroban-env-host-curr] | ||
| package = "soroban-env-host" | ||
| version = "=27.0.0" | ||
| git = "https://github.com/stellar/rs-soroban-env" |
There was a problem hiding this comment.
With the current host coming from this git source while soroban-env-host-prev remains the crates.io 27.0.0, Cargo.lock now contains two soroban-env-host v27.0.0 packages from different sources. The dependency-sanity-checker still parses only 27 from Cargo.toml and runs cargo tree -p soroban-env-host@$PROTO, which is ambiguous for same-name/same-version packages from separate sources (verified against Cargo package selection), so the required dependency-check workflow fails before reaching the XDR comparisons. Please make the checker use a fully-qualified package ID/source, or otherwise avoid the duplicate soroban-env-host@27 package spec.
Useful? React with 👍 / 👎.
Two changes to scripts/check-dependencies.bash, both needed for the protocol-28 transition state where rs-soroban-env's next-protocol work isn't yet released to crates.io: 1. `cargo tree -p soroban-env-host@27` is intentionally ambiguous when -prev pins crates.io =27.0.0 and -curr pins the upstream git rev (with the `next` feature on). The script now detects the 'is ambiguous' error, extracts the candidate sources, verifies each resolves independently, and accepts the result. 2. `p-expect.txt` from stellar-core is fetched per packaged-core protocol leg. For CAP-0083 / consensus-only P28 the core build at ff61f2e6d doesn't yet ship a p28-expect.txt (404). Treat the 404 as a skip (with a Note line) rather than a hard failure — the previous- protocol leg still guards the rs-stellar-xdr revision Core actually compiled against.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 502c521fc0
ℹ️ 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".
| if [ -n "$SOURCES" ]; then | ||
| ALL_OK=true | ||
| for SRC in $SOURCES; do | ||
| if ! cargo tree -p "$SRC" > /dev/null 2>&1; then |
There was a problem hiding this comment.
With the current lockfile there are two soroban-env-host v27.0.0 package IDs, one from crates.io and one from git. I checked cargo +1.95.0 tree --help, which documents -p, --package [<SPEC>] as selecting a package spec; passing only the extracted source URL from line 32 is not a valid spec (locally, registry+... is rejected as an invalid package name). In the ambiguity path this makes cargo tree -p "$SRC" set ALL_OK=false, so the dependency-sanity-checker still fails instead of accepting the intentional split; use a source-qualified pkgid that includes the package name/version.
Useful? React with 👍 / 👎.
| # guards the rs-stellar-xdr revision Core actually compiled against. | ||
| if ! CORE_HOST_DEP_TREE_CURR=$($CURL https://raw.githubusercontent.com/stellar/stellar-core/${CORE_CONTAINER_REVISION}/src/rust/src/dep-trees/p${P}-expect.txt 2>/dev/null); then | ||
| echo "Note: stellar-core ${CORE_CONTAINER_REVISION} has no p${P}-expect.txt dep-tree fixture; skipping the Rust-vs-core XDR check for protocol $P." | ||
| continue |
There was a problem hiding this comment.
Fresh evidence after the earlier P28 dep-tree comment: this handler now continues when p28-expect.txt is absent, but the P28 workflow leg uses core revision ff61f2e6d while the P27 leg checks 7696c069d, so there is no later/previous iteration that validates the P28 core image's actual host dep tree. In the consensus-only P28 case, the dependency check passes without comparing the rs-stellar-xdr revision for the core binary run in integration tests; fetch p27-expect.txt for the same core revision instead of skipping.
Useful? React with 👍 / 👎.
The 3348 vnext build aborts during catchup's bucket-apply step with: mStates.rbegin()->first == seq - 1 at main/QueryServer.cpp:124 That's an assertion firing inside the QueryServer rework that landed between 3312 and 3348 (commits 'Move historical ledger management to query server' and 'Cleanup historical ledger query'). It blocks every backfill test (TestBackfillEmptyDB and friends) and any test that exercises the daemon's in-process captive-core catchup path. 3312 predates the QueryServer rework, so its catchup completes normally. Bump once the upstream stellar-core fix lands.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0997c7cbf1
ℹ️ 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".
| version = "=27.0.0" | ||
| git = "https://github.com/stellar/rs-soroban-env" | ||
| rev = "883fd56374fc619afaa4c4c7489563555b7173f2" | ||
| features = ["next"] |
There was a problem hiding this comment.
With this line, curr::PROTOCOL becomes 28, but curr::recording_auth_mode in cmd/stellar-rpc/lib/preflight/src/lib.rs still calls recording(..., false) for use_address_v2 even though that comment says the legacy setting is only until v28. For P28 simulateTransaction calls that default to record mode when no auth is supplied, RPC will return legacy Address credentials instead of AddressV2 credentials, so clients get auth entries that cannot be used for a P28 submission. Please flip only the curr/P28 recording path to use_address_v2 = true.
Useful? React with 👍 / 👎.
During a protocol-next transition the Rust side (via rs-stellar-xdr) and the Go side (via go-stellar-sdk) routinely regenerate at slightly different stellar-xdr commits. As of this PR, go-stellar-sdk is at 8521b97 and rs-stellar-xdr is at 68fa1ac5 — diff is one stellar-xdr commit, a comment-only fix that doesn't affect the on-wire XDR. Use GitHub's commit-compare API to check whether one is an ancestor of the other (status: ahead/behind/identical). When yes, warn but don't fail — both sides will converge before merge to main. When the commits diverge into different ancestry, that's a real branch mismatch and we still hard-fail.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 32d9a128ec
ℹ️ 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".
| AHEAD=$($CURL "https://api.github.com/repos/stellar/stellar-xdr/compare/${STELLAR_XDR_REVISION_FROM_RUST}...${STELLAR_XDR_REVISION_FROM_GO}" 2>/dev/null \ | ||
| | $SED -n 's/^[[:space:]]*"status"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' \ | ||
| | head -1) | ||
| if [ "$AHEAD" = "ahead" ] || [ "$AHEAD" = "behind" ] || [ "$AHEAD" = "identical" ]; then |
There was a problem hiding this comment.
When the Go and Rust XDR pins differ but are on the same branch, this now turns the dependency check into a warning. In this PR that is exactly the risky case: Go records the CAP-0083 stellar-xdr commit while Rust still reports the v27 stellar-xdr baseline, and same-ancestry only proves one commit descends from the other, not that the generated wire schema is identical. Fresh evidence beyond the earlier dependency-pin comment is that this new branch explicitly lets the sanity checker pass with those mismatched revisions, so incompatible Go/Rust XDR decoders can reach CI unnoticed unless the exception verifies the actual generated schema or is scoped to the known equivalent commits.
Useful? React with 👍 / 👎.
stellar-core#5329 (merged at 3589a696b) fixes the QueryServer.cpp:124 assertion that aborted captive-core catchup's bucket-apply on builds 3313..3366. The new build 3367 is the first vnext deb that contains the fix. Plain vnext variant (no ~buildtests) to mirror the P27 leg's variant choice. Docker stays at 3312 vnext since no vnext docker image for 3367 is published yet — the validator container doesn't go through the fresh-DB+catchup path and so doesn't trigger the assertion.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a49f53f0d3
ℹ️ 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".
| git = "https://github.com/stellar/rs-soroban-env" | ||
| rev = "883fd56374fc619afaa4c4c7489563555b7173f2" |
There was a problem hiding this comment.
This git curr dependency now has the same package name and version as the new crates.io -prev dependency, but the scheduled .github/workflows/update-soroban-env.yml still runs scripts/update-soroban-env.sh, which calls cargo update -p "soroban-env-host@${current_host_version}". I checked cargo +1.95.0 update -p soroban-env-host@27.0.0 --dry-run --offline, and Cargo reports that spec is ambiguous and asks for the registry/git source-qualified package IDs, so the every-12-hours protocol-next updater will fail until the script targets the git pkgid explicitly.
Useful? React with 👍 / 👎.
The plain jammy-vnext docker image for build 3367 was published a few hours after the buildtests/perftests variants, so docker and deb pins can now both reference the same QueryServer-fix build.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e8733a25bc
ℹ️ 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".
| # fix for the QueryServer.cpp:124 contiguous-snapshot assertion that | ||
| # aborted captive-core catchup on builds 3313..3366. | ||
| core_deb_version: '27.0.1-3367.3589a696b.jammy~vnext' | ||
| core_docker_img: 'stellar/unsafe-stellar-core:27.0.1-3367.3589a696b.jammy-vnext' |
There was a problem hiding this comment.
In the P28 leg, the reusable workflow runs docker pull "$CORE_DOCKER_IMG" before any tests start. The vnext tag 27.0.1-3367.3589a696b.jammy-vnext is published under Docker Hub's stellar/unsafe-stellar-core-next repository, not stellar/unsafe-stellar-core, so this new job will fail at the image pull (or stop exercising the next-protocol image if a similarly named non-next tag appears). Point this at stellar/unsafe-stellar-core-next:27.0.1-3367.3589a696b.jammy-vnext to run the intended P28 core container.
Useful? React with 👍 / 👎.
The host window in workspace Cargo.toml moved (-prev: 26.1.2 -> 27.0.0, -curr: 27.0.0 -> rs-soroban-env git rev with 'next'), so the dispatcher now routes proto<=27 to the prev host and proto==28 to the curr host. P26 ledgers fall through to a host built for P27 and fail with HostError(Context, InternalError); P28 was missing from the list and silently uncovered. Update the unit-test list and the docstring to match the new pair. Local 'make build-libs && go test ./cmd/stellar-rpc/internal/preflight/...' passes after the bump.
1 participant
SPIKE — depends on the go-stellar-sdk CAP-0083 XDR regen (#5952). Stays draft until that merges.
Changes
cap_0083feature to the workspacestellar-xdrdependency (Cargo.toml); version pin unchanged,Cargo.lockuntouched.go-stellar-sdkto the #5952 review head4615d5e8viareplace(go.mod/go.sum).replacedirective in.golangci.yml(gomoddirectives).Deferred
replace→ tagged release and drop the.golangci.ymlallow-list entry once #5952 merges, then mark ready.Upstream: stellar/go-stellar-sdk#5952
Downstream: stellar/stellar-horizon#196