Skip to content

Conversation

karthikiyer56
Copy link
Contributor

PR Checklist

PR Structure

  • This PR has reasonably narrow scope (if not, break it down into smaller PRs).
  • This PR avoids mixing refactoring changes with feature changes (split into two PRs
    otherwise).
  • This PR's title starts with name of package that is most changed in the PR, ex.
    services/friendbot, or all or doc if the changes are broad or impact many
    packages.

Thoroughness

  • This PR adds tests for the most critical parts of the new functionality or fixes.
  • I've updated any docs (developer docs, .md
    files, etc... affected by this change). Take a look in the docs folder for a given service,
    like this one.

Release planning

  • I've reviewed the changes in this PR and if I consider them worthwhile for being mentioned on release notes then I have updated the relevant CHANGELOG.md within the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.
  • I've decided if this PR requires a new major/minor version according to
    semver, or if it's mainly a patch change. The PR is targeted at the next
    release branch if it's not a patch change.

What

[TODO: Short statement about what is changing.]

Why

[TODO: Why this change is being made. Include any context required to understand the why.]

Known limitations

[TODO or N/A]

Comment on lines +1 to +2
// SEP-48 Contract Bindings
// Auto-generated from Soroban contract specification
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😯

} `json:"params"`
}

type GetLedgerEntriesResponse struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't you use stellar-rpc/protocol and stellar-rpc/client?

Copy link
Contributor Author

@karthikiyer56 karthikiyer56 Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will give you the reason why i did that, and i dont want you to laugh at me.
I did not want to create my own repo and then include go monorepo and stellar-rpc as dependencies.
I wanted to do this PoC in the go mono repo itself. If I included stellar-rpc, that wud have been a circular dep.

So...
I fed exaclty 2 files to claude.
https://github.com/stellar/stellar-rpc/blob/main/client/main.go
and
https://github.com/stellar/stellar-rpc/blob/main/protocol/get_ledger_entries.go
and told it to come up with minimal code to create my own rpc client in go monorepo just to get ledgerEntries functionality.

And it worked 🤷

which is also why this doesnt do any kind of error checking if there is an error returned by the RPC instance

	contractResponse, err := client.getLedgerEntries([]string{contractLedgerKey})
	if err != nil {
		return nil, fmt.Errorf("failed to fetch contract instance: %w", err)
	}
   
    // I dont even check for Error from rpc here

	if len(contractResponse.Result.Entries) == 0 {
		return nil, fmt.Errorf("contract instance not found for ID: %s", contractId)
	}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants