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.
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
[pallet-revive] add tracing support (3/3) #6727
base: pg/add-tracing-support-2
Are you sure you want to change the base?
[pallet-revive] add tracing support (3/3) #6727
Changes from 3 commits
f3b3d0e
7c06a39
c17c94c
b66aec2
db77731
e5314b2
807ebd6
3fbcaed
ce2ff1e
92ae9ad
2e16534
a37a5ef
0189fb8
8b34beb
01c2ebc
c484137
0641eeb
b09394f
505d89f
d9b0b2c
dbed695
e356429
3adbc1a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Do you know "ballpark size" of the response for
ReviveApi_trace_block
?The reason why I'm asking is because
--rpc-max-response-limit==10MB
by default and maybe worth adding a comment about it whether one needs a bigger limit for this RPCThere 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.
Good point I will mention it in the doc
People running this will probably do it on a dedicated "tracing node" where they can tune this up.
Similarly, can the wasm heap memory @kianenigma be tuned up for this kind of "offchain" call?
For validators, I understand this is defined on-chain, but I want people running such "tracing node" to be able to adjust it.
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.
Could we build this entirely with the new RPC APIs instead? We plan to revisit the legacy ones soon and deprecate as much as possible.
One way that this could work without introducing the
debug_block
RPC:Step 1 (maybe optional): Let the user call into archive_unstable_header. This maybe needed because the implementation below calls a runtime API at the parent hash of the desired block. If the user knows the parent block (ie because they might have subscribed to chainHead_follow API), then this call is entirely optional.
Step 2: Let the user call archive_unstable_call with the newly added
ReviveApi_trace_tx
runtime methodOverall the code looks good 🙏 I feel like
debug_block
is a tiny wrapper that could live in a separate repo, or the users can rely onarchive_unstable_call
entirely. Would love to get your thoughts on thisThere 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.
Hey @lexnv thanks for the review, sorry for the slow response, I was trying to test this end to end and it took more time than expected.
I wasn't aware of the new "unstable" APIs.
So all I need is a mean to call my runtime api from "parent_hash" and pass it the block so I can replay the block with the executive pallet inside an environmental context that will set the tracer first so that we can capture traces.
If we can port the "debug_block" fn to the new unstable APIs then it looks like this should be a simple port.
Do you mean polkadot-sdk crate / rpc folder ? This will be a core feature of Plaza and needs to live in the mono-repo
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.
No, the idea is that someone could implement this on the "client-side" like CLI tool which under the hood would do two RPC calls (not adding a new server API called debug_block):
For example you could add it
eth revive proxy
instead since it already is using subxt... but we need to add the "archive API" in subxt which is missing but that should be trivialThere 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.
Ok going with that so we don't have to touch the legacy endpoints, will update the PR
thank you both for the review
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.
I don't get why you should pass the
name: String
here? If this RPC is only to callReviveApi_trace_tx
, it should hardcode it?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.
also asking better docs as to what each param is in general, RPC docs are important and get propagated into PJS/PAPI.
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.
ah maybe this is not the one that is meant to be used by end users?
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.
+1 for the docs, added more details.
A few reason, We have 2 runtime methods that make use of this. One that replay an entire block, the other that replay a single transaction. Replaying a single transaction involve that you replay all the transactions that precede
to ensure that it's replayed from the same state that when it was executed.
Also potentially other Runtime API could make use of this, so hard coding it does not make much sense 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.
I wonder whether these could be pallet specific RPCs/runtime APIs for pallet-revive instead of "state_debug_block" because from my understanding it supposed to be used for "ReviveApi_trace_tx" and "ReviveApi_trace_block"?
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.
I thought it was pretty generic and potentially useful for other pallets that could setup tracing features in a similar way.
It can't just be a runtime API as it need to load the runtime and the blocks before passing it over to the runtime api that will handle this data
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.
In general I'm quite reluctant to add new stuff to the legacy RPCs but this is fine by me.
You didn't look into implementing this on-top of https://paritytech.github.io/json-rpc-interface-spec/api/archive_unstable_body.html?