-
Notifications
You must be signed in to change notification settings - Fork 35
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
fix: use both traceStartBlock calls where appropriate #1711
Conversation
Signed-off-by: Luis Pinto <[email protected]>
|
public void traceStartBlock( | ||
final BlockHeader blockHeader, final BlockBody blockBody, final Address miningBeneficiary) { | ||
try { | ||
this.hub.traceStartBlock(blockHeader, miningBeneficiary); |
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.
Here you use the 2 parameter variant of traceStartBlock
?
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.
Yes, if you look at how it was before it was like this: https://github.com/Consensys/linea-tracer/pull/1694/files#diff-72836d8f02f4d5b6e4bfe40f1d1f199abcfefab3f5326c30d4c5e2c40808623fL185-L194
It seems that on the contrary we are now using |
Also I count 15 occurrences of the previously dominant signature traceStartBlock(BlockHeader, Address) In the repo (prior to this PR.) Will those have to be switched over to traceStartBlock(BlockHeader, BlockBody, Address) ? |
I did a grep for occurrences of
|
That's a good question - I don't think you will have to do anything from now on. But I suspect that, after this PR, you have some trace methods declared that are not used. But at the same time I want to avoid having to change |
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.
LGTM
fix compilation in BlockCapturer Signed-off-by: Luis Pinto <[email protected]>
Quality Gate passedIssues Measures |
I rolled back usage of
traceStartBlock(BlockHeader, BlockBody, Address)
where appropriate because I feel we shouldn't be changingTraceServiceImpl
on the Besu side just to fix the linea tracer. This avoids an inconsistency betweentraceStartBlock
andtraceEndBlock
and also opening a can of worms going through yet another round of consensus as to why it was done like that in the first place.I see that your tracer implementations were implementing both cases at the same time, so it's hard to see which is definitely being used, but given that we have to modify
TraceServiceImpl
to make things work I would saytraceStartBlock(BlockHeader, BlockBody)
was definitely being used.Also with this you don't need another release from linea-besu to make the tracer work as both
traceStartBlock(BlockHeader, BlockBody, Address)
andtraceStartBlock(ProcessableBlockHeader, Address)
already exist.