Expand getNetwork endpoint response with core supported protocol version info (P25) #563
+66
−7
Conversation
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
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Shaptic
reviewed
Dec 9, 2025
Member
|
The linked issue is quite old. I'm posted some thoughts on whether it is still relevant and asking about what the use cases are for exposing the different versions here: #17 (comment) |
Member
This is interesting. It looks like we have two formats for capturing events evolving in different tools, and we should come up with a way to derive them consistently from network data and use the one format where-ever possible. @sisuresh Is there a formula that stellar-core uses to map the config ledger entries to soroban-info response from stellar-core which is being exposed here, a formula that doesn't require knowing the names of the configs ahead of time? Or is it a manual mapping? @sisuresh If the format is a manual mapping today can we change it to be derived from the XDR names, so that we can define a way to programmatically map from the configs ledger entries -> core and rpc settings json, so that we can mirro that behaviour in tooling like the cli? (cc @fnando @mootz12) We should figure out this story before releasing this in RPC, since it's a more visible endpoint and harder to change once released. The other format that's being used for network settings is the raw XDR form, used in the stellar-cli and quickstart:
|
Contributor
|
the I believe the |
Member
This basic structure format is easier to read. It's a better developer experience. The upgrade XDR is harder to work with. Could the basic structure be expanded so that it is not only a subset but covers all settings, and doing so in a way that's defined programmatically? That method doesn't have to be complex, it could be just flattening the XDR structure. For example, one idea:
|
Member
|
The existing basic mapping is still so much easier to use and understand. Maybe we just duplicate that in the other tools. @sisuresh Could the mapping be defined in a SEP? We can adopt it in stellar-cli and offer the same output options (just two: the sep format, and the raw xdr format). The SEP will just need updating when the XDR gets new. And RPC can continue to do what it is doing in this PR already. |
Contributor
I'm hesitant to do something like this because it'll add a format we'll have to maintain. As you can see, we haven't even maintained I also don't think the basic format is really that much better than the upgrade xdr other than the omission of the cost types, but I'll defer to you on RPC UX matters. My vote would be for RPC to make the cost types optional, or maybe add that as an option to |
Member
|
Yeah that's fair, if we can't maintain the format, let's not do it. A better developer experience is only achieved if we can commit to maintaining it, and in lieu of that exposing the raw XDR 👍🏻, and as you say, RPC could just omit the two long cost type lists if the use case limits are being added for don't need them. @Shaptic you mentioned at #17 (comment):
What's the use case we're exposing the limits for? Limits are already collectable via the |
Contributor
|
@leighmcculloch tbh adding the limits just seemed like a nice-to-have: a convenient, human-readable place to check the network's limits instead of perusing stellar.expert or relying on human docs: I wasn't aware of However, I just realized that since So I think I agree with the general sentiment here that maybe we shouldn't do the same thing in two places in different ways and just point people to the CLI command (which maybe can just filter out the verbose cost functions). |
Shaptic
reviewed
Dec 10, 2025
Co-authored-by: George <Shaptic@users.noreply.github.com>
Member
Opened: |
cjonas9
changed the title
Shaptic
reviewed
Dec 10, 2025
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.
What
This PR adds
coreSupportedProtocolVersioninformation to thegetNetworkendpoint to provide the protocol version that core supports.See this PR for changes made to
go-stellar-sdkthat must be merged before this is.** sample query/response **
Why
The
getNetworkendpoint provides less information than what's exposed to us by core. See discussion at this issue.Known limitations
Version info extraction is fragile. Specifically, to get this information, because it's not included in any endpoint but rather in the
stellar-core versioncommand, a regex is used to capture what comes after "ledger protocol version:" in the output of that command. If core changes the wording of the output ofstellar-core version, this endpoint will fail gracefully.