-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
Add dev-inspect-txn to RPC and SDK #6998
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
results: DevInspectResultsType; | ||
}; | ||
|
||
export type ResultType = 'Ok' | 'Err;'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@666lcz is this the right way to handle Rust Result
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Result will deserialize to {'OK': [(),()]}
and {'Err': ""}
. The best way to figure out the schema is to write a ts e2e test
returnValues: ReturnValueType[]; | ||
}; | ||
|
||
export type MutableReferenceOutputType = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@666lcz This is a tuple in Rust, I saw codes around using structs like this to handle tuple in Rust as well, so presumably this should work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work. It will just deserialize to a list. Can we change the type of mutable_reference_outputs
on the rust side to a struct instead of tuple?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM so I'll accept to unblock, but noting that there are some questions for @666lcz on the TS SDK side.
Let's definitely add TS e2e test for this given so many newly added types since it's hard to verify by human eyes |
Closing this in favor of #7008 |
Same as #6998 but - fixed typescript types - Relax RPC restriction for calling non-entry functions Co-authored-by: Ge Gao <106119108+gegaowp@users.noreply.github.com>
Same as #6998 but - fixed typescript types - Relax RPC restriction for calling non-entry functions Co-authored-by: Ge Gao <106119108+gegaowp@users.noreply.github.com>
This PR is based on #6538 and exposes the dev-inspect endpoint to RPC and SDK.
Testing: WIP and will add in a bit.