Update the Horizon-to-RPC guide for CAP-67 events that already shipped - #2724
Open
ElliotFriend wants to merge 3 commits into
Open
Update the Horizon-to-RPC guide for CAP-67 events that already shipped#2724ElliotFriend wants to merge 3 commits into
ElliotFriend wants to merge 3 commits into
Conversation
The endpoint-mapping table and the getEvents warning both described CAP-67 unified asset events as future work, with "when available" and "when expanded" qualifiers and a warning that the method "in the current protocol only include events from contracts". CAP-0067 has been Final since Protocol 23 and the live networks report Protocol 27, so a reader migrating today was told to plan around a capability they already have. Rewrites those spots in the present tense and names what CAP-67 actually covers: transfer, mint, burn, clawback, fee, and set_authorized. Keeps the meta XDR path for the effect types CAP-67 does not model, such as signer updates, data entry changes, sequence number bumps, and offer management, rather than implying getEvents is now a full replacement for Horizon effects. Closes #2699 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Horizon-to-RPC migration guide to reflect CAP-67’s Protocol 23 availability.
Changes:
- Documents supported unified asset events.
- Retains meta-XDR guidance for unsupported Horizon effects.
- Needs qualification that classic events require
EMIT_CLASSIC_EVENTS=true.
Recommendation: NEEDS-CHANGES — address the event-configuration caveat.
Suppressed comments (1)
docs/data/apis/migrate-from-horizon-to-rpc.mdx:72
getEventsdoes not always return classic-operation events merely because the network is on Protocol 23+: their emission depends on the backing Stellar Core node settingEMIT_CLASSIC_EVENTS=true(docs/learn/fundamentals/stellar-data-structures/events.mdx:177). The unconditional wording is especially risky in a migration guide because a self-hosted deployment without that data will silently lack these events.
Since [CAP-67] shipped in Protocol 23, the method returns events from classic operations as well as from contracts. Those unified asset events are emitted as `transfer`, `mint`, `burn`, `clawback`, `fee`, and `set_authorized`, so a single stream now covers the movement of assets and changes to trustline authorization.
| | [`GET /ledgers/{seq}/operations`] | [`getTransactions`] | Use [`getTransactions`] for the given ledger, then parse the transaction's XDR for individual operations. | [Operations](../analytics/hubble/analyst-guide/queries-for-horizon-like-data.mdx#operations) | | ||
| | [`GET /ledgers/{seq}/payments`] | [`getEvents`] [`getTransactions`] ⚠️ | Use [`getEvents`] (specifically CAP-67 events when available) and parse [`getTransactions`] meta XDR to identify payment-like operations. | [Payments](../analytics/hubble/analyst-guide/queries-for-horizon-like-data.mdx#payments) | | ||
| | [`GET /ledgers/{seq}/effects`] | [`getEvents`] [`getTransactions`] ⚠️ | Use [`getEvents`] (when expanded to cover all effects with CAP-67) and parse [`getTransactions`] meta XDR for relevant data. | [Effects](../analytics/hubble/analyst-guide/queries-for-horizon-like-data.mdx#effects) | | ||
| | [`GET /ledgers/{seq}/payments`] | [`getEvents`] [`getTransactions`] ⚠️ | Use [`getEvents`] (CAP-67 asset events, emitted since Protocol 23) and parse [`getTransactions`] meta XDR to tie those events back to individual operations. | [Payments](../analytics/hubble/analyst-guide/queries-for-horizon-like-data.mdx#payments) | |
Review feedback, verified against stellar-core's example config and the canonical events page: classic operation events are not unconditional on Protocol 23. Stellar Core only emits them when EMIT_CLASSIC_EVENTS is set, which defaults to false, and ledgers from Protocol 22 and earlier also need BACKFILL_STELLAR_ASSET_EVENTS. Softens the unconditional wording, adds the configuration requirement to the warning block with a pointer to the Events page, and notes it in the payments row. Without this, an operator running their own RPC without the flag would follow the mapping and silently receive no classic asset events. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Verified and addressed in c7e671a. |
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (1)
docs/data/apis/migrate-from-horizon-to-rpc.mdx:74
- This makes
BACKFILL_STELLAR_ASSET_EVENTSunconditional for self-hosted RPCs, even though it is only needed when replaying Protocol 22-and-earlier ledgers (as the preceding sentence andevents.mdx:177state). Protocol 23+ mappings require onlyEMIT_CLASSIC_EVENTS; requiring both overstates the configuration and may trigger unnecessary historical event generation. Keep the backfill flag conditional on needing pre-23 coverage.
Classic events are not on by default. They are only present if the Stellar Core instance backing the RPC runs with `EMIT_CLASSIC_EVENTS=true`, and covering ledgers from Protocol 22 and earlier also requires `BACKFILL_STELLAR_ASSET_EVENTS=true`. If you run your own RPC, set both before relying on this mapping. If you use a provider, confirm with them. See [Events](../../learn/fundamentals/stellar-data-structures/events.mdx) for more detail.
|
Preview is available here: |
Review feedback. "Set both" contradicted the sentence before it: the backfill flag only matters for ledgers from Protocol 22 and earlier, so a Protocol 23+ mapping needs EMIT_CLASSIC_EVENTS alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Valid, fixed in the latest commit. "Set both" contradicted the preceding sentence; backfill is now scoped to pre-Protocol-23 history only. |
|
Preview is available here: |
|
Preview is available here: |
This file contains hidden or 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
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.
The endpoint table and the
getEventswarning still described CAP-67 unified asset events as future work ("when available", "when expanded", "in the near future"). CAP-0067 has been Final since Protocol 23 and the networks are on Protocol 27, so readers were told to plan around something they already have.Puts those spots in the present tense and names what CAP-67 actually covers (
transfer,mint,burn,clawback,fee,set_authorized). Keeps the meta XDR path for the effect types it does not model, such as signer updates, data entry changes, and offer management, so this does not overcorrect into implyinggetEventsfully replaces Horizon effects.Closes #2699
🤖 Generated with Claude Code