Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong type in GetEventsRequest interface #893

Closed
fazzatti opened this issue Dec 14, 2023 · 2 comments
Closed

Wrong type in GetEventsRequest interface #893

fazzatti opened this issue Dec 14, 2023 · 2 comments

Comments

@fazzatti
Copy link

WHAT:
RPC calls to getEvents fail with:

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason 
"#<Object>".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

WHY:
Testing further we could find the root cause for the issue.

startLedger?: number; // either this or cursor

The parameter startLedger under GetEventsRequest is set as a number, while the getEvents expects it to be stringified. See this doc for reference.

Forcing the parameter as a string, fixes the issue and returns the correct output from the RPC server.

@Shaptic
Copy link
Contributor

Shaptic commented Dec 14, 2023

Two questions:

  1. What version are you using?
  2. What Soroban RPC version and network are you targeting?

This change actually done intentionally as part of the v11.0.1 release, because the type had changed to a number. You can confirm this in the source code: see get_events.go. That build of the RPC server is currently deployed to futurenet, so if you are targeting testnet in your software, you should be still be using the latest v11 beta of the SDK rather than the stable version (i.e. beta.6).

I believe that documentation needs to be updated, so thank you for noting that!

@fazzatti
Copy link
Author

Thank you so much @Shaptic !

Indeed I think you're spot on! I/m on v11.0.1 and targetting testnet!
I'll switch all testing to futurenet to make sure to focus on the correct build of the RPC. What sent me off-guard was that I was testing in parallel using the testnet RPC and the validation cloud API, which are probably both using a similar build because I got similar results.

Sorry for jumping the gun!

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

No branches or pull requests

2 participants