RPC Standards #15

Transcript

Loading developers...

[music] Heat. Wonderful.

>> [music] >> Thank you. >> Heat. [music] [music] Heat.

>> Heat. Hey, heat. Hey, heat.

>> Water Jesus. No recording.

RPC Standard Call Introduction

Okay. Um so good afternoon everyone. Um welcome to RPC standard call 15. Today's date being October 27th, 2025. Um currently we have three things on our agenda and whatever that again we we want to discuss that is not yet on the agenda. Um the first thing will be handling of um the error handling for block not found which was raised by Mark which I'm not sure he's here but do we have any impute on that? I shared a link to the issue on our chat.

So I'm not sure if we have anything if we have any contribution in respect to this but Mark is not here to show more light on this. So unload. >> Hey, sorry. So I think it might help if we discuss it um in a bit more detail. So this is about the specific tests, right? >> Yes. >> Yeah. So specifically it's about the get lock receipts.

Yeah. So seems that can we go about the what is the specific question? So in the the pull request just changes BU to return null instead of returning an error. So I guess the question is if that is a valid behavior or is it should we change something or I think the it looks to me like from the poll request that the problem is that um

fixing this like get block receipts um hive tests break the simulate v1 Um I'm not sure about the details about it but I think from the uh the request it was it mentioned that it's there's an inconsistency in in error handling behavior like the expectation. So what is the output is not what is expected.

The entire details is what I'm not sure about because I've not like looked into it myself. But um if anyone has an idea or can help us understand this much more better or a better way to go about this then the floor is theirs. >> Yeah. So the way we I see it is that the basically they they they are changing it to fix the tests but somehow it yeah I mean I don't really see why they're not why they are not so it it breaks the test e simulate v1 empty with block num set plus one or something like

that because e simulate v1 seems to have the different handling. So I don't really understand him. It just means they have to implement it different for the e simulate. I mean here he's saying that they have this abstract class that is used by several RPCs. So yeah, if they if they change it in this abstract class, it will affect but this just sounds like a biso problem to me. like yeah I mean they have to fix it but it's it's not I mean ultimately the be the defined behavior in the spec is that if the block is requested but the block is not found then it's supposed to return null and the not found is not an error

condition that's just how we always have defined it in the specification so and it's how the other methods handle it as And just for clarity, does that mean that >> um okay, there's an expectation that a block should be found and it's not found and then it throws an error or is it just like Yeah, >> I mean there's a difference between the block not existing and there being an error accessing the database for example. So if there's an error while trying to load the block from the database, then that is an error. But just the basic idea behind returning null was always that when you're trying

to access for example a block number that's higher than the current one shouldn't necessarily be an error because you just cannot know if this block is like existing or not. And I mean it will exist in the future. So it's a bit of a different kind of error from that was always the the whole idea behind this basically that you you when we can tell you're trying to do something impossible we will tell you with an error but if we can't then we shouldn't define it as an error per se.

So it's more like that or if we know it doesn't exist then it's also not an error right like that's the other thing for example there's a bit of a thing like we have the same behavior for example when you're trying to access a transaction by its hash so if if the transaction doesn't exist we return null but yeah it's just that's just how we always had it in this API Hi. >> Okay. Sorry. Um according to what he said, he said um it returns the basel returns an error but this um but the test is expecting a success um response with null result.

>> Yes, exactly. So when it's not found then it's supposed to return null as the result. Yes. So we can check it actually in hive. So we I I see they are failing quite a few tests. But for example, um let me try to see. So they have this get block receipts not found. Yeah. So they return error code minus 32,000 for this case. And I guess it's do they have it in another case? I'm checking the test for Bisau right now to see which ones no

it's only this one. I mean it's it's basically as as he was writing in the PR description. It will fix three hive tests or something but not more of them. Yeah, this like get block receipts empty future or not found. Yeah, I'm less sure about this empty test. What this is even about see it maybe. Ah. So okay. So in this this get block receipts empty test it accesses get block receipts with the hash value that is all zeros. So the whole idea is that

basically it's using an invalid block hash that we know doesn't exist. Notably, they do return null already for, for example, get block by number or get block by hash. And they also already return null for the get transaction by hash when it's not found.

>> Sorry, I'm not quite sure if I understand this. So are we saying that it's bessu problem or the specs and the hive test are inconsistent in terms of um handling errors and what is expected. >> So I think this is a bizu problem because that's what I think because the the the bizu itself is also a bit inconsistent. The spec is pretty clear and all the other clients adhere to it in this case. So it's just that BU doesn't and in fixing this they seem to be creating some issue with the e simulate but this also I would regard as like a BU issue that they they basically fixing it on their side seems to have some effect on the E simulate v1 but

then I guess they just have to fix that one as well. I have no idea what he wanted to discuss about it. I think maybe he wanted to bring up like changing simulate v1 to have the similar behavior or something like that. I don't know. >> So it looks like to me that the um the simulate like if you look at a simulate empty with block num set plus one, it's a future block and it's throwing an error. A block not found error like should that or should that throw an error? Is it are you are you putting that into like the impossible bucket? like this is

Error Handling Discussion: Future Blocks

impossible because it's in the future. >> I mean you could say I mean this is weird. I mean this is the same question would for example apply for the ETH call right and I think we're missing a test there. So we would have to create a test that runs ETH call with a future block and we have to decide about the behavior of this. Um the whole idea with returning null is that it's supposed to return null when the item which you are seeking is not found. So it's like when you do get block by number with the future number then and the block doesn't exist in the node it should return null.

But if you're trying to execute an ETH call on a block that doesn't exist, probably that should be an error. Do you understand the distinction between these two cases or is it weird or I don't know. So to recap from the outside, it's saying you're [clears throat] saying like okay uh if it's a normal like everything is wellformed uh and you don't find this block and you like even if it's in the future then that should return null. But if for some reason it's like I don't know a malformed block number [clears throat]

uh it should return an error. Uh >> yes. Yes. >> But also it's it's like it's a bit like the return null is a bit like the error 404 in HTTP. It's like if you you wouldn't you would only give the error 404 in HTTP if the exact resource which is being requested doesn't exist. But if there's a problem like if there is an internal problem accessing the resource like a problem in the server or something then it's not going to return 404. is going to return something else like some other error. So in some ways this return null thing is a bit like returning the 404 in HTTP. So yeah, I mean in the future we could define an

error code that is specifically about like this condition that it's not found. The thing you were looking for is not found. But right now we don't have this defined error code at all. So we are and we have been using this return null convention since the beginning of the API. So I feel like I mean yeah we can change it in the future maybe. Don't we have something? I'm not

>> I'm sorry. I have some trouble understanding you. >> Is it just me or I can't hear him? >> I I couldn't understand him either. Okay, I think we just wait for him to

join or fix his mic. Fix, sorry, you were saying something before you got caught up. >> No, not really. It's okay. I just tried to explain again like this difference between the I think this could be one action item for this. Basically, we need to create a test that tries each call with some future block or something. I think that's that's possible. We don't have that now, I think. Let me see. No, >> can you hear me now, guys? >> Yeah, that's better. >> Okay. My point was I think we have something like uh something similar to resource not found which we use for example. So there is an error code that

could be used here if I'm not mistaken, but I'm not at the computer at the moment, so not not entirely sure. >> Yeah, I mean we don't really at the moment there are no really defined error codes. I mean we will be discussing the error code proposal later. We have some other error codes but we don't have a general error code for not found. It doesn't exist so far. Yeah, it would have to be added and then we would have to define it and for check change all the servers and change the spec and change the test and so we don't have that now. Basically now right now for most methods which can return a result we have this convention that their

result is either null or it is an object or something like that. I mean I don't find it pretty either with the null. I have to say like I wrote the Go RPC client for the API and it's kind of annoying. You have to pay attention to this null thing all the time, but I guess it is what it is now. So yeah. >> Okay. I don't know how >> sorry. Go on. >> I have actually two different topics uh Fix that I wanted to ask you. Uh one is the uh reverted error code. Uh we changed it to three recently, right? But I think the ETH simulate tests weren't

Reverted Error Code Update Discussion

updated and they still are using the old revert top code uh error code. >> Yes. Yes. Yes. We would uh we can discuss it. Yeah. But um this this update is in progress. Yes, they will be updated. But we have to if we all agree on this call that this change should be made to ETH simulate, we can definitely make this change. We have a pull request for it. Go Ethereum. We can regenerate the test with a different error. It's it's all there but we have to agree it today. >> Well, we we merged the spec, right? So, I think the reverted error code will be consistent between different calls.

>> Um, yes, that's true. However, I not sure if we really did change it in also the simulate. Um >> well, you didn't definitely. >> Yeah, at the moment I don't see that. So, we did not change the spec for e simulate to have this error code defined. It is something we can do. I mean, yeah, we can change it to the error code 3 as well. I have no problem with that. I really just wanted to say that we have to um we have to agree at first. I mean I I

agree with it. Yeah, let's go. But right now if we didn't >> Yeah, it's inconsistent. I agree with that too. Yeah. Yeah, it is inconsistent right now. Yes, definitely. It's because this proposal with error code 3 and the proposal for e simulate happened in the same time. So yeah, it's kind of and on a long time scale. But how about this? Maybe we should follow the agenda first and then because at the end of the agenda is not very long. So we can just after the agenda maybe bring this up again. Yeah.

>> Okay. That would be great. C I think you're next on the agenda about um execution API versioning. >> Yeah. So, this actually sort of segus into what I've been thinking about a lot, which is that we should uh version execution APIs so that um clients aren't trying to hit like a moving target. And so, I mean, I think in an ideal world, we'd get all the like ETH simulate v1 tests passing before we like tag execution APIs. Um, but I think in lie of that, I think we can kind of like tag it. I'd like I I'm preferrantic

versioning. Um, and so I think we can tag execution APIs either in like a beta right now or just tag it with something and have Hive run those tests. And then um if we're doing like bug fixes or like things like the youth simulate error codes, I think those can kind of fall into like bug fixes and then we can have hive pick those up. But then next time we make like a big breaking change like e simulate for example adding that um we can kind of do it all at once and warn people and tell them that like you know something's going to break. Um, but wanted to get a feel for like

Versioning and Bug Fixes Discussion

what people's thoughts were on that or if that was a bad idea. I'm a fan of it. [laughter] Uh, I like the idea of uh having Zimb. And then I would say uh probably just maybe put a versioning MD just so people know the rules around what is like a version bump and what's not like what's each of the patch for patch minor and major um what those will mean.

>> Cool. Yeah, I think that makes sense. Yeah, I I think it's actually a good idea and also it will help us with error code so that we can easily clients can easily adapt to it in terms of adaptation. So >> I'll try and get that implemented before next meeting. >> Okay. But do you do we have any plans on it already on how we're going to go about it? More like an MD file to this or I mean I think we just need to do it. Um so I think the steps are a file um tag it as it is and we can kind of address

um you know things that come in issues and PRs that come in and decide if they're bug fixes or um or features or breaking changes and then yeah have a change log and tag it and then have pick it up. I have a local PR to have hive pick up a certain tag so I can I think it'll be pretty quick. >> Okay, thank you. That would be great. So, next on the agenda will be the three PRs. Um I think this has to do with your car cuz you have the right subion API. If you could help us look at the pair and if

Review of Pull Requests and Log Filtering

there's review or anything else that needs to be done then that will be fine or further discussions also on it. Yeah. One second. Let me just uh see uh either of us can share the screen. Uh let me see where where we got that. So one sec. Uh yeah.

Okay. Can you guys see it? >> Yep. >> Okay. >> So I I thought we would try this because we have the um we have this thing with the pull request triage in in in Gothereum as well and it's been pretty useful. So I thought maybe in the future if you know if we would tag some of the pull requests here and then just look at them. I tagged these more as an example because I feel we should discuss them and they seem to be unlike the other ones. For example, the fossil specs huge thing. We're not going to review that today and it's like related to some future protocol feature but for example this one is very small.

So it's something we can easily discuss on this call I feel because we just have to make a quick decision about it and um this pull request is about adding in the spec an option that has existed for a while which is that in get logs there are now two options. So the current in the spec currently it only allows specifying a block range and a filter. So the block range is defined by from block and two block and then you have the optional addresses and the topics and the topics they are sort of like defi they the address and

the topics they define a kind of filter that has to be matched by the logs. So um this PR is about adding another option which is the block hash. So when this is specified instead of giving instead of specifying a range of two numbers you can query the logs of a specific block which is identified by the hash. It is a useful um it is a useful thing for some clients to be able to access just the logs of uh a specific block and also to be able to filter them.

Um yeah, I initially thought we we have to um we would have to uh you know agree on on this but actually um turns out that this EIP was proposed in 2017 and it is final. So I guess this is official and we could just merge the PR. However, this is not supported by Nethermind at the moment.

>> Yeah, sure. We can add support. It's not a big deal. Uh one question, uh is there any uh what's the behavior when the block is non canonical? Because we don't have blocks. It's probably undefined, right? There's no definition of error code. >> Yeah, I mean there's no there this I mean that's that's this is now the interesting question like where we are back now to this to this uh uh to this question of should it return null or not. I think in this particular case maybe not because basically the intention for you is not to access the block. It is to access the logs and if you specify and also you're specifying the block by

the hash. So it's kind of like the intention here is to say um you want to filter logs contained in a specific block. So if that block isn't there then the operation you wanted to do is impossible. >> Mhm. So it maybe should have an error. >> Yeah, exactly. Another thing there is for force, right? So we need to specify that for for errors also. >> Yes, that's true. That's true. That's true. That's true. So yes, exactly. When the this needs to Okay, this is a good point. But um I think maybe we can we can do it in this PR or not.

For me it was >> if we won't do it in this PR we will forget about it. >> Okay. [laughter] Interesting. Yeah that's definitely one way to see it. Let's see. Um I don't know exactly. >> At least I will forget about it and then I don't care that much about JSON RPC to keep that in in my mind longer than five minutes. >> Yeah. Uh, I don't know what's your GitHub name, by the way. >> Uh, Lucas Rome, >> like my normal name without Polish characters.

>> And Well, one sec, guys. I need to pick up

the phone. I'm sorry. Okay. All right. So, yeah, I'm back. So, that's a that's a good point. Can Can we still I mean, I can take care [clears throat] of the error codes. Do you if you guys agree, we can just merge this. I mean, this is I checked it and it appears to be implemented uh in most uh clients. >> Just Okay, cool. Sorry, I clicked on my own name. Um yeah. Okay, cool. So, we will merge this and then that's that.

Um, yeah, it's a bit weird that this has this like oneoff definition, but I guess that's just how it is. Open RPC. There's not really a better way to do this. So, yeah, I guess we have the I mean, it's going to look okay, I guess. In the website, you have these two options, filter by range or filter by block hash. And then, yeah, I guess that's it. Cool. So, that was PR number one. Um, now the next one is maybe a bit more complicated. So we >> you're going to track that error implementation or you want me to put up an issue?

>> I mean I can do it right after the call basically I thought. >> Cool. Thank you. >> So the next one is for the ETH config. So um technically I think ETH config is final right? >> Yeah I think so. >> No it's last call. Okay. So and the last call ends tomorrow. >> [laughter] >> Okay, I didn't know that. But yeah, I mean I don't think expect that anything will be changed anymore in ETH config. Um it seems that this is also adding test cases. Um the thing about the test cases is we

ETH Config Finalization Discussion

will have to redo them. So it's always the problem that when test cases get submitted like this, we have to later kind of turn them into like because we use the generator to create the test. we kind of have to backport them into the generator after this. But I think I mean this is a very well specified thing and I I'm I'm sure that since everyone is working now on the uh Fusaka fork and this was included in the Fusaka fork and decided by all core defs, this is for sure implemented by everyone and uh would be good to have the test for it.

So I don't think we're going to change anything about this PR, right? I mean this this is just it's just a matter of merging it I guess. So yeah I mean if you guys have any kind of lastm minute reservations about it we can still change. >> No I think this is a good one to get in. >> Yeah. Cool. So and then I guess with the test also we need to see uh I think there must be something there. Yeah. In the RPC test gen. I mean we can check if there is a matching PR.

Um, nope. So we need to sorry just one question. Um, I saw the io file from on this. So if there's no test for it. So how come the io files are generated? >> What do you mean? >> So I'm lost. I on the rp. Yeah. Here there's aio file.

>> H. >> Yeah. So how come the test we have aio file but we don't have a test? >> I mean the this is maybe something where also like because I recently reviewed your PR mercy on the on the RPC test. So R RPC test just it RPC testion is not the tests it's just the test generator. So the IO fails are the tests and um they are created by this tool but they don't have to be necessarily I mean I guess the that uh uh uh what's his name again? I forgot. Dano just uh created these tests somehow using his own tools.

I guess using Bisu or whatever he created them and then now it's kind of on us to make sure that as we keep regenerating the tests they will always be up to date. So this is like the thing the IO files they contain the IO files are tests which are which correspond to the current test chain also like that's a thing like in inside of the test folder we have the test chain and this test chain you can see it here there's this like chain.rlp and then like the genesis and so on. So these files they define like

the blocks which exist in the test and so on. And the ETH simulate uh the the ETH config tests here they somehow correspond to they somehow correspond to uh this test chain but uh we we have to backport these tests into the generator. So basically we have to update the generator to actually call ETH config and basically recreate these tests so that when we update the test chain the next time these will not go out of date or something because then you know the maybe the block hashes will change or something about the config will change or you know like anything like the fork ID or like all of these things will change over time and in order to make

sure that the tests will remain up to date we have to kind of make sure that these tests are created by the gener generator as well. But the the pull request authors in execution APIs, they don't always know this. And I mean, I don't think they can always be expected to uh update the generator with their test. So, usually what I would say is that we just kind of add the test that they created or something and then we just have to backport it. Like that's how I would it's just how I would say it's the easiest.

No. Okay. So, I was thinking we do the um we do RPC test first before putting it to the um um execution repo. >> I was thinking it just has like um a unified format like a step. >> Yeah, it's true. I mean, we could totally do that. Yeah. So, basically here we would have to say Okay. So that's what you mean. Yeah.

That it has to be created first. >> So I guess in that in that case I mean someone maybe you can actually do this. I mean you have updated the RPC test gen before. So basically what needs to happen is the it has to be changed so that the RPC test calls ETH config two times once with no parameters and once with wait also no parameters. Yeah, that doesn't work. No, that's weird. So that's not that's not these tests will not work because it calls the same method two times and it has a different result. That's not how I don't know.

Does it even take parameters? >> Uh, does it even take parameters? Yeah, I guess it it doesn't. Yeah. Okay. There are no parameters. Okay. Interesting. So in that case it means basically we can only keep one of these tests.

Challenges with ETH Config Testing

Yeah. So we will only have a single test for each config which is the one that returns the current >> sidebar question here. Um are both tasks important in terms of like syntactic correctness for returning results depending on the state of the chain? Yeah, I guess so. I mean, this this is kind of the problem with ETH config in general that it's kind of is one of the aspects of econig that I personally don't like. It's that it the result is dependent on the current block in the client. So, if if the I mean it's like if you schedule a fork in the client

then and the client knows there will be an upcoming fork, it returns something else in ETH config compared to when the fork is over and there is no currently defined fork. I think it's a pretty weird distinction. We cannot actually test it using our current setup because there's no way for us to I mean I guess we could make a custom hive test that launches the client with a fox scheduled in the future, but that setup doesn't exist for the RPC compatibility tests. We would have to basically it would be like a specialized test. So uh just out of another sidebar takes dev work but uh it seems like maybe there's needs to be an additional

parameter that specifies chain state or some way of specifying the chain state uh required for making each of the uh RPC requests. >> What do you mean? Um so um because you call Eve config, right? But there's an expectation of different responses per chain state. Um so it seems like the tests need to specify what the chain state is uh or what's chain state to like load for then like validating that the response is correct.

>> I mean we have we yes but we have that. So we have a single test chain which is defined and so that chain we just use it for all the for all the tests. So basically the expectation is that before any of the tests can run the client has to load the defined test chain and then it's going to be in that state and I guess we could add a second set of tests that run against a different chain or something like that but yeah that's >> I guess I I'm trying to see like how do you solve the get config with next fork and get current config issue >> and then it seems like there's like a couple of ways you could do it. to one is like you could play forward the sequence of like RPC calls to then put

the chain in the state the test chain in the state that then allows you to validate it. Yeah, but we can't really do that because we can't we I mean we could like start talking to the client over the engine API to advance the chain somewhere else, but it's not really I mean the the the way the test chain works right now is that the um so you can see it kind of in this in the in the genesis, >> right? It's just a static it's a static state. I mean it is a it is a it has to load the chain but then also the the chain is kind of set so that when the client is finished importing has finished importing all the blocks in

chain.rlp it will have passed this prog fork. So the prog fork here is kind I think is kind of the latest fork. it will just it will just go past all the forks basically. So we can't really schedule a future fork in the tests because we the tests are supposed to like when the test at the end of the test chain all the forks are passed [snorts] all the all the ones that exist. I mean >> yeah that makes sense.

I mean, we could kind of stop import like we could make another test chain that like stops before the be before the before the proc fork or something. But then that's that's like really weird. We only need it for one test which is the ETH config. So this kind of like ETH config is kind of hard to test in that way. It's even hard to test like in general because most of the time there's no next fork. The only time when ETH config returns even something for the next fork is well when when the clients were just updated uh to to you know support the fork.

I mean I guess this is a valid this could be interesting. We might just discuss this today in Discord since the last call of ETH config is not yet passed. So, we could just technically bring it up and be like, "Hey guys, why don't you just change eat config to remove this next fork thing?" I don't know. [laughter] Seems a bit wild, but I guess it's not too late formally. Anyways, yeah, Lucas, you were saying you need to go. So, could we just finalize? I mean, this PR I think in I would say we can kind of merge it because it is it implements the EIP at the same time. The EIP is in last call. is not final. So maybe it's too early and also we need to make the generator. So maybe Mercy, you

can just add this call to the generator. That would be great. And then we can update this PR with the generated test and there will only be one test for now. Do you think that's a good resolution? Okay, super cool. So let's go like that and then we can have some progress. So basically then it will be all good in terms of the process and I can ping Dano to figure out what to do about this next fork thing. Okay. And so now let's maybe quickly go and see the final one. So the final thing that was tag for triage is this uh JSON RPC error code standardization. Uh this is kind of a big thing. So

JSON RPC Error Code Standardization

I don't know how far we're going to get. Definitely some some things were changed after the last call where we discussed this. >> Yeah, I can quickly update it. Um just like in 2 minutes. Uh in short uh I adjust most of the comments uh change the ranges to positive uh for the newly implemented ones and most importantly for execution errors uh at least for the execution reverted it now reflects three um and rest of the transaction pool and um zk executioner is a new category I added and gas errors I've reduced the number of gas errors to only reflect the error that we actually get uh at least

with get and basu. I cross checked it with the test. I also created new test suit. This is currently in my um profile. I'll slowly start working on moving it to hive or RPC test gen. But that has the updated report. So if you click on the last point in the eat error test um in the in the just uh in the description, it's in the description at the at the bottom. Oh no, it's all the way top in the PR description.

>> I shared it in the chat. >> Oh yeah, thank you. Yeah, that one. >> Oh, the tests. Ah, okay. >> Yeah, yeah, yeah. Yeah, exactly. So, I created my own. So, it's based on the existing test I did long back and uh I updated to include all scenarios. So, the reports now will have I only did for Solia, get and basu. Uh it's but it's easy to append for rest of the clients to add it. Uh it's sort of like a sim very similar to hive. Uh how it spins up local clients and runs scenarios. Uh but just as is my own structure. Uh but can I I'll start working on expanding this for rest of the clients. But if you click on the

reports and pick up any one of the report CSV, it's in the uh folder reports folder. Yeah. Uh you could click on get if you want. Yeah, CSV. Yeah, >> nice. Uh you can see the raw transaction and those are the errors I added in the gas errors. Uh and this will reflect error code and uh I've simulated this in on actual by deploying actual contract and uh simulating this exactly how how it would respond. But for some scenarios uh it's not too perfect. uh I cannot replicate the errors such as nons to high uh but that can be addressed and there are a few hacks here to get it all printed out but pretty much should work

still uh for most of the clients and I've done this again for baso too so I can expand this test too to cover more scenarios u but if you click on the test cases folder under the package and send transaction scenarios at the end uh I haven't done the estimate cast it's currently only on send transaction scenarios. Uh so if you click on the send transaction scenarios file. >> One second. >> Sure. I'm sorry. Yeah. Um, all right. Uh,

Testing and Simulation of Transaction Scenarios

yeah. What should I click on? Sorry. >> Uh, no worries. No, all good. Uh, send transaction scenarios. >> Uh, yeah, that's the one. So, this has all the tests that I did. Um, basically, you know, u uh updating some of the params to simulate different kinds of errors. Uh, but this is up to date. Uh I need to implement the same for ETH ETH and call ETH call but Ethan transaction should be should have all the latest values. >> I need to fix the code a bit but >> it seems kind of interesting to me. I mean we should some I there's a lot of overlap in this with both uh RPC test gen and with the hive. So right you should just kind of convert this to run

in the hive and then we would >> I I agree completely agree. uh the just one the only reason I I didn't do that now is because I wanted to get this done quickly and I had the setup ready in my local >> so just sort of expanded on it uh but it would take a little bit for me to move this to hive and RPC test but it's all simulating really actual native uh errors. Yeah. Yeah. Yeah. I mean this is very good. I I have a general feeling that might actually be useful now that we think I think about it to maybe just also run RPC test gen inside of Hive. So this is something that we could do because um at the moment it's like we own we you in RPC test gen we run G to generate the the test cases because uh

Test Case Generation and Client Testing

it's easiest for us to just like compile and run it in the same setup. >> But that doesn't mean that >> it would actually be kind of interesting to fill the same test from another client just to see the results. It doesn't necessarily mean we have to commit them or something. It's just more like at the moment it's literally not possible to to to to do the filling like I mean yeah it is some manual stuff but I guess so there is some overlap with that too. >> Yeah no I I agree uh this is like a single package where you can add new client and run all the test in one go.

Uh but definitely the end goal is to move this to um hive and RPC test gen once I have like nailed it down. The only reason I didn't do it is again >> Yeah, but this code could basically be used as is to generate the test cases, right? Like that's the main thing. Yeah. >> Yeah, exactly. No, I kept most of the stuff very similar. Uh so we can it'll be easy to import later. Uh but yeah, this is what I have so far. I mean the question is also like I mean this is more like this this project is more about doing like some research in terms of like what the clients actually do right now but obviously it's not like what they are doing right now is not necessarily what we want to put in the

spec right we want to >> correct exactly >> more for like you know having an overview of like where the clients are at >> and I guess now Wukash left but like he is was from Nethermind so I guess it would have been quite interesting to to hear it from him Because like I mean Nethermind isn't here but obviously they also have some they also have some error. >> Yeah I can add the Nethermind quickly. It wouldn't wouldn't take too long. Uh just probably under a day I can add never mind quickly. Yeah but uh yeah this is just to showcase what where the clients are and even if you want to run after fixes this would reflect the current state and the future state.

>> Pretty much. >> Yeah. Very cool. Very cool. So, um, can we maybe go back to the So, what we gonna do about the PR? I mean, >> for now, I guess now it's I think it should be really ready at this point. Uh, if you all take a look into the actual numbers and see if it matches and uh, sounds good, I think we can we should be in a position tomorrow. There may be like one final commitment. I have to do some cleanup just uh some description and read me but other than that the PR and test should be should be in a good condition.

Discussion on PR Readiness and Error Handling

Um I have the general uh comment I think that the um these two groups are not required to specify because JSON RPC allows the server to return these errors anyways. I mean it's just going to be like if there's a server error then yeah it's going to return this error. Do you think it's required to put this in for every single method to define that you know the standard errors can be returned? >> I don't know bit it would be useful in the future test. Uh if it doesn't match it should at least warn us. U let's say someone is using completely outside the JSON standards or the errors we've defined. uh we should at least see them

uh warn a warn message or at least error it out. So and and of course it's like a single place to look up all the errors that currently is supported and that's the only reason. Uh probably I can do this even more slightly generic. Uh I can take a look at that but um yeah it'll be useful for the test in the future. >> Yeah. Okay. >> Actually implementation. Yeah. Mhm. Yeah. I Okay, so I mean this is definitely improved compared to last time. Let me put it like that.

But I mean, yeah, it has some has some good things, but some not so I mean mostly yeah, it has the the ZK arrows now. These are new and then some of the some of them have to be reduced. I still think we should maybe for example one of the things that's a bit weird still is this message and data situation here like >> that I mean I know last time we talked about it but like the message here is this is very confusing I have to say because this says message already known but this is more like a >> right >> I don't understand like what's the distinction between these two fields like there's a message and then there's also the other message more like

readable Right. So yeah uh I can also revert back uh I didn't I didn't keep it to cause confusion. The more goal was for me to uh you know push people to start using the data field uh more often. Uh that could be a string that could be an object. Um and also this also gives us a way to standardize the message field a little bit more. uh if uh you know clients want to say out of counters or or transaction uh not permitted some kind of error um that's not defined um or well known just like non-sto because non-sto everyone knows it's pretty standard and everyone

has similar uh string for rest of them we can also kind of use this kind underscore messages to standardize messages in future but absolutely not needed now so we are only focusing on code. If it's causing more confusion, I think we should we we can revert this and move the description into the message field and leave the data out of the standardization. Uh but so that is just to point what can be used for this uh error code. That's it. Yeah, >> I would be on board with the like maybe moving the the stuff that's in data into message >> because yeah, >> from the open RPC side, >> it's kind of like maybe an early days

misstep where >> yeah, like Shane said in the comments that it should be like the data field should really specify a schema. So like imagine that you're out of gas. we could define schemas that client should return um toert client with that. So it could be like oh gas field plus number um that kind of thing. >> Uh so the more that we can push into message then whenever open RBC does the the version bump to support like the data schema um that could be like it's going to be a seamless transition then.

>> So here Yeah, that sounds good. I'm showing [clears throat] this on the screen right now but basically we have for the existing code three we have the data which is defined to be the schema so it's like a bite this this is kind of the the the intention between the intention of using the data field so for this error >> of code three we don't expect the client to return this exact message that's kind of the point of error codes that they don't have to agree on the message 100% we will never check that we will check the code and we do have to check the data as well that like they return the correct thing in the data and the tests will verify that also. So we can't make if the I know that for example ref

currently returns some other like they they have it a bit like you have it in your proposal where they have like some error message in the message and then they have another error message in data but that's not really how it's supposed to be used. >> So yeah. >> Yeah. No. Uh yeah that that definitely makes sense. I can move the data field into message. Uh just want to make sure that uh people don't cross use the messages or or cross use the error code for different kind of uh errors. But absolutely that makes sense. I can move the data into the message field and leave the data out of the proposal for now.

Error Code and Message Field Discussion

>> Yeah, I would say because we will define we will define like additional error data when it's necessary. just we haven't really had that that happen so far like for now >> it hasn't really been the case that we need uh we need the error data or something like >> that makes sense uh like mentioned >> yeah yeah like Zayn mentioned when they have implemented the schemas for uh data we we can start using it for now I can move it yeah I think uh that makes sense >> that should be a quick change too uh I can do this before tomorrow and uh send it out on the channel. But if you have anything else also, happy to do it so we can get this merge really quick.

>> Yeah, I mean that and then I guess we're kind of good. We have to review again like all of the defined error codes if they really make sense, but for now it's I think it's moving towards the the good state. I would say like with this like definitely we're we're on it now. Yeah, >> sounds good. Thank you. >> Sorry, I just wanted to add um if in case you make the changes, we can then move it over to the ACDT call so that they can all other clients can actually like look more into that and if they have any specifics then that would be great.

Next Steps and ACDT Call Preparation

But let's say we are we bypassing the safe zone. Yeah. >> Yeah, that makes sense Mercy. for sure. Uh I'll try to get this done uh quick so maybe before next week we can take it to ACD call. >> So I guess that's the last thing on the agenda. So any last comment? Oh okay. So before we close, I just wanted to say um I wanted to make out some changes on the documentation uh on the website itself.

But when I'll make up a PR and then I will send the PR link so we can further discuss because we already like we're over time now. Um that's all from my end and it was nice having you all and having these discussions. Thank you everyone. Thank you. Bye. >> Thanks. Thanks everyone. Bye. Heat. Heat.

>> What's up? Thank you. [music] Heat up >> here. [music]