eth_simulate Implementers' Meeting #55

Transcript

Hello. >> Hello. >> Yeah. Um, I don't know. I sent you a link. I sent a link on the chat. If you can kind of like look through it. It's about the error codes and then where they are currently at current. What they have currently >> in which chat >> here on Zoom. >> Oh, sorry.

>> And about our issue, I don't think white client has had time to take a look. I don't know what a step counter is. It's a very bizarre execution error. Oh, I see something specific to Polygon,

I guess. Yeah, I don't know. It's um I can't comment much on the new error. It's I think the question is is do we want the execution API to include things for not Ethereum like for Ethereum like clients. >> Okay. >> Cuz that's not I don't think that's an Ethereum thing. I think that's a Polygon thing.

>> Okay. So like what's your um general um suggestion? >> What's my general what suggestion? >> Uh I have no idea. I mean this is more a political question than anything else. The on the one hand if you have the execution specs um having more data in there is generally useful. it can be allow people who are building things that makes it easier for them if everything's in one place. On the other hand, there's, you know, 10,000 things calling themselves L2s, the vast majority of them are not actual L2s. Um, deciding which ones to allow to add things to the Ethereum specs is a

very difficult challenge. You could just have someone in charge of it and then you're going to get people that are upset they don't get don't get included. If you include everybody's stuff, then the spec becomes just overwhelmed with a bunch of garbage from a bunch of third party things that no one actually cares about. Is this not an easy an easy problem and again it's it's mostly political. Thank you. Oh, okay. Sorry to ask just a bizarre question.

Was Cena affected by the um get and Ethereum Foundation um what I call it issue or propaganda? Don't even know. >> Not that I know of. Sorry, one last thing um about the issue we had. I noticed that um the reason why we had that issue is because the spec um the spec check doesn't run it runs independently.

I think we have to like somehow extend it to run immediately after the test to kind of like check for any malformed cases. It runs. It doesn't run when someone submits a PR. I looked at the GitHub action. It looked like it was running when someone submits a PR. But yeah, this is what I'm saying. Like we need to like make it run immediately after running generating the IO file. It you like kind of like make it run after that. I don't know if what I'm saying is making sense.

>> Are you saying the issue is it runs in the wrong order? No, not like it runs in the wrong order, but it should be that after the test gener the files is generated, it should run. >> And you're saying it's not right now? >> Yes, it's kind of it's independent. You have to like call it for it to come out. It's just there. It's more like it's a dominant future. If you call it, it comes. If you don't, it just stays there. But I don't know how the CI is structured. This is like from what I saw from the RPC test genle cuz we are trying to like build um okay let me check the workflow.

>> So that that is the GitHub action that is running the checker and that checker looks like it's running against excuse me the pull request this question. This is what I looked at and this is the action that failed. And it looks like that action is trying to run the checker against the pull request. But for some reason, it's not. But that's that's where I would I would start is figure out why this why spec check.

Like you could probably just clone this locally and see what happens. So um you can clone this repository onto your your computer do the all the steps here. So you would clone repository npmci npm run build npm run lint um and then go install spec check and then spec check-v and then try making a change to that repository. So make something that you know will cause that should cause the checker to fail and then run it again and see if it fails in that case. If it does then I have no idea what's going on. If it doesn't fail then that gives you at least a hint or at least a place

to start on how to troubleshoot it. >> Okay. What I'm saying is if this is the exact step I follow to reproduce the issue. If you run it, it come but like we need to like make it the way that issue. I don't know why it's not running immediately you submit a a pull request. It should be once the io files is generated the check the spec check runs immediately after like without you waiting to call it yourself because for you to like see you have to run um spec check v um dashv that's when you can like get it.

I don't know. I don't know how to put it. >> I mean, it should be doing everything in this file is is run every time someone submits a pull request. >> Yeah. What I'm saying is it should run before you even submit a pull request. >> No, no, no. You you should run you want it to when So, you want the CI to run on the CI server when a user submits pull request and when they make changes to the pull request. And GitHub the way GitHub handles this is anything that's got that runs on pull request will show an error. Um GitHub.

So this is what makes it so the pull request they got those little checks on them. This is the way you get one of those checks on the pull request. And so that way when someone submits pull request everybody can see does this pass the checks? And for some reason, our pull request passed all the checks. And that's the part we don't know why. We don't know why our pull request passed because it shouldn't have. Okay, that makes sense. >> But I guess it's like line need to like come in a little bit.

What was that? >> Light client. Uh yeah, he might know if he he wrote it, so he might have some ideas. I don't I don't know exactly how spec check works, so I don't know what it's doing. Um it does appear that the action is running properly. >> Still need to investigate some more. >> Okay, I think that's all for me. >> I generally don't have contribution and it simulate itself.

It's fine. I'm guessing everybody is at a conference. >> Would you go for Defcon? >> I I did not know. I don't know what conference ethc is right now. >> Yeah. I'm asking like are you going to defcon like for >> No, I don't go to any conferences. >> Why? >> Because I don't like leaving my house. Actually, you're right. This maybe this action is set up wrong.

I don't actually see this action being called anywhere. lint and check. Sorry. Yeah. Okay. So, the action looks like it's set up, right? So looking at the action history, it is getting called every time somebody makes a commit on a checked repository.

Yeah. So the issue isn't that the check isn't running. The issue is that the check didn't run for us. So the question is why didn't it run for us? And we don't we don't know the answer to that. Why didn't E simulate get I mean it did. So let me rephrase that. E Simulate did have the checker run and the checker said everything was okay and so we merged it because the checker said looks good. >> And another point to look at is killer I think he wrote the test for um um the ROPC test then on the API um side this person uploaded the test himself. I don't know his name. FGI. I don't know if you know him. He works for get

because if you check the um if you check the code um history and then on the io files itself, it was uploaded by it wasn't I don't think I don't know how but he was the one that uploaded it. Look at it here. >> Are you referring to FJL? >> Yeah, him. >> That's Felix. He's on the guest team. He um does a lot of the networking code and testing stuff. >> Oh, sorry. I thought he was better. >> I don't know anything about the test setup though. You have to talk to Gloria or Cena or Felix.

I think Cena might actually like have better understanding. >> Very very likely. >> Yeah, it looks like the the checker even passed when our code was merged into the main branch. So, not only just when we made edits did it pass, but it also passed when our PR was merged. is confusing to me.

>> And it is currently failing with the fix we put in, which supports my theory that the issue here is that the spec check is running against head, not against the thing that should be checked. like it's checking the wrong thing. It's basically checking to see if the last code that was committed prior to whatever code you're trying to commit is good. It should be checking the code you're trying to commit, not the code you're committing into.

Okay. Um, yeah. So, for getting that fixed, you're the all I can really advise is figure out. So, one thing you can do if you wanted to try to do something is clone the repository and then run it locally. Spec check should pass then make a change to the actually no. So clone it, run it locally, spec check should pass. Then you should be able to apply the fix that Gari has a PR out for number 670. And then after applying that change, then run spec check again and it should pass. It should fail initially and then pass after.

For some reason, CI is not that is not the case. Another option is wait for like client to get back to you and help explain what's going on. like I I don't know enough about spec check to give much more advice than >> Okay, thank you. >> Yep. >> Okay, it doesn't look like anyone else is going to come. So, see you guys next week. >> Bye.