Changes to support the API changes upcoming in rpc v22

[leighmcculloch]

The rpc client needs updating to support the following changes that are upcoming in rpc v22:

• createdAt field in getTransaction response is now encoded as string instead of int64
• The fields in getVersionInfo response were changed to Camel-case naming:
  • commitHash
  • buildTimestamp
  • captiveCoreVersion
  • protocolVersion
• The legacy cost object has been removed from simulateTransaction response.
  • The correct resource costs can now be retrieved from the transaction XDR instead.
• Remove pagingToken from getEvents response and replace it with Cursor.
  • Instead of being present in all event objects, the Cursor will be at the top level of the response similar to getTransactions. This makes it easier to use and brings it in sync with how Cursor is used in other RPC endpoints
• Deprecated getLedgerEntry endpoint is now removed.
  • Users can use the more powerful getLedgerEntries endpoint to get the same result.
• Add transaction hash to getTransactions response.
  • Each transaction object in the response now also includes a hex-encoded transaction hash string.

Ref: https://gist.github.com/aditya1702/8a0e3e05689217009692517d744c7f10

Related discussion:

• https://stellarfoundation.slack.com/archives/C0445GF868N/p1727957758063739?thread_ts=1727909447.005259&cid=C0445GF868N

The above list of changes include breaking changes. Some of the breaking changes are changes to the response fields, and there is not time period for where both old and new respond fields will be present to allow clients to adopt just one or the other at any one time, so when updating the client to support the new fields the client must be able to support both the old and new fields.

This may require rewriting the way the client parses the JSON, introducing custom parsers, or parsing some fields into dynamic json values, and then parsing them manually to one of the types we expect.

This change is a dependency of releasing the stellar-cli for protocol 22.

[willemneal]

See #https://github.com/stellar/rs-stellar-rpc-client/pull/12

[willemneal]

there is not time period for where both old and new respond fields will be present to allow clients to adopt just one or the other at any one time

I'm confused why need backwards compatibility. When pointing at an RPC endpoint that supports v22, why would we need to support the old fields? If needed couldn't the old client be used with an older RPC endpoint?

[janewang]

@willemneal Spoke with Molly and that platform team is unavailable next week as the whole team is onsite. I think given you already opened the PR, I assigned this to you. Thank you!

[leighmcculloch]

I'm confused why need backwards compatibility. When pointing at an RPC endpoint that supports v22, why would we need to support the old fields?

A developer might be building for mainnet and testnet at the same time. They'll have a CLI installed, and new CLI's should be backwards compatible with the current network in use. Otherwise we end up with a poor developer experience where developers need to have multiple versions installed, actively switch between them.

Also, operators will need to deploy the new RPC ahead of network upgrades, and operators of those RPC shouldn't need to coordinate with users of the CLI. Users should be able to grab the new CLI, then at some point operators upgrade the RPC and the user is largely unaffected or doesn't care.

If needed couldn't the old client be used with an older RPC endpoint?

Most of the breaking changes are changes only in the response, which means the CLI can't know which client to use until it gets a response back and need to parse it.