RPC Standards #8

Transcript

Heat. [Music] [Applause] Agenda is listed. I'll post

recording in progress. Thank you, Puja. I will post the agenda here in the Zoom. Uh I don't see any new additions to it, so we can get right into things here. Okay, first up on the agenda, we had some discussions last week uh about uh Gatsby uh its adoption versus Docsaurus. We decided to go with Gatsby and it looks like there is a PR in flight courtesy of Acolyte to make the switch back to Gatsby.

Uh, great work. Anything we need to discuss here or is it just a matter of peer reviewing it and getting it merged? As far as I know, it's ready to for final review. I know that um Mercy added a couple things, just cleaned up some of the naming on the sidebar and um Zayn has put made a few changes for us on the generator side to make it a little easier to manage. So, it's not quite as hacky as it was um when I first did it. So, I feel pretty good about it at this point. Um, just in perfect terms of like getting the everything up and running and kind of back on back using the generator code as opposed to the where we have now with the old PR or the old plugin from Docsource.

So, awesome. Great. So, we just need review and merging. Um, I I will note that the the tests are not passing, but that's because of the e simulate PR that uh Felix merged a few weeks ago that that the tests weren't passing on that when he merged it. And so that's not the fault of my PR. I think I did clean up the the spell check stuff just because that was easy to do. But um so that's curious. All right. Like they they were if you look at if you look at the PR that Felix merged, the tests were failing there, too. So, I haven't I haven't looked at that. I think there might even be a PR to fix that. I haven't looked closely at that yet. That's kind of like a day two, day three kind of thing for me once this is

done. Yeah, the issue um Mike talked light client about it. We I noticed about the spec check. I don't know how he was able to mesh without the whole thing running but I think um Killer made an um a in respect to that. So I guess if it gets B the thing will clear up and then we can look into the check itself. Okay, that's slightly worrisome. We should probably do something about that.

I don't know if anybody has any background on like kind of what happened here, but um yeah, merging and breaking the build for future users is suboptimal. Yeah, I mean I think the simulate PR had just been sitting there for 18 months and there was some conversation and Felix was just like it has to get merged now and it's not really great that it broke things. Yeah, I mean that's exactly what happened. That's probably the context. Okay. Okay. Oh, that needs to be unbroken ASAP, I guess.

Yeah. And I can take a look at that um once this is done. I mean, this this is the ma the only major docs PR that I'm going to do. There's another one. I have another one just like some more DevX kind of improvements for down the line. Like, but that's they're not as important. Like this. If we get this merged, it cleans up the table rendering issue um in the simulate docs and it updates our, you know, it puts us on the right thing with the open RPC generator and fixes the spell check. So I can take a look at that other broken test um after this maybe alongside working on spec check itself since I'm starting to think about that. What a segue.

Sorry, one other question on the docs. Yeah. Is the long-term goal to stay on Gatsby or was there some plan to switch to doc source again in the future when more of the plugins or infrastructure is updated? I think that's a long-term goal from according to what open said it's a long-term goal for the open RPC. Yeah. They have a I think I mean Zayn you're on right you want to talk to it you mentioned something about it so like it's on a road mapap for um this upcoming year to overhaul the documentation generation so it's just like

um and it seems like a lot of people are kind of on this kind of docysurus tip and so the idea is that we'll probably lean towards um developing something that looks more along the lines of like nitlifi um but with a docu source space and like just clean all of that up. But the Gatsby is just kind of a hey look let's uh make sure that we're tracking the changes in the um open RBC like ecosystem um because we like overhauled a lot of the underlying things and then you won't be able to support extensions and other code fixes. So this will just get you tracking.

Sounds reasonable. Sounds good. I'll take a look at the PR for Gatsby. Thank you. Light client get merged today. Awesome. Awesome. So, next up, uh, spec check. We had an outstanding question about spec check. Um there's a little bit of a some brokenness that sounds like folks are looking into and also a question as to whether or not um it needs to be integrated into the local build processes that developers use as well as CI.

So um can anyone elaborate on the question and figure out uh what exactly needs to be done here? It sounds like it's just kind of open up a couple issues and you know sort out some of the CI/CD infrastructure. Does that sound reasonable? So, a couple of comments. So, the CI for the does use spec check. It runs it. Um, it's not I don't think it's integrated in any of the package JSON scripts for local use. I think you have to actually manually install it and run it. I think it's not hard. Just it's not we just don't have a we just don't have a a script set up to do it. That's I could add that. it would be relatively straightforward to do.

Awesome. Um, so in and of itself, it's not hard to use. It's it's already running on the CI. So that which is why the test job fails because it runs this back check and there's a a broken simulate test. Um the I think the bigger question and here again I know that like client mentioned you know when our chat um adjustment you and I have had with him about is it I guess there are certain things when it's validating when it when it validates against the the um the spec against those um the generated tests I think it's it's not validating if something's not present that maybe should be or something I I need I just started looking at that this last this last week and so um so it's not that it validates you But if the elements that are there, it

validates. But my impression is from looking at is like if an elephant an element is not present, it doesn't necessarily fail that um that test. It just ignores it. I think so here again some of that goes back to the underlying code that like client put in there that that actually compares the schema against the against the um the test output. And that's that's not a simple matter to solve for. I need to I'm I'm still learning kind of how the open RPC spec is put together versus the the libraries that actually do the the spec because it it's not it's not custom code. It's we're using handic I think like client you're using the that that JSON schema validation library from it's

a go one he's on there's a newer version of it and then there's you know anyway so there's some work that needs to be done to looks like the also looks like we're not validating against the correct version of the scheme I don't know there's it's a lot of like down a rabbit hole kind of stuff it's not bad as is it just it's not 100% perfect so What I'm hearing is that this isn't necessarily a challenge with spec check itself. It's just the tests that the authors are writing lack negative testing. Uh no, I think that spec check doesn't validate. Like there like for example I think the one that the li client pointed out was in the 7702 test like you're supposed to have a certain like there's an element in the JSON or

the for the transaction for the 772 transaction you're supposed to pass in a data field and if it's not present um that's an invalid it should it should be rejected by the RPC but the but that that field element is not there and spec check doesn't doesn't highlight that as a it should be a required field and it's not highlighting it as a required as an example. I think I think that's what I understood from looking through that. Understood. Yep. Great. Is that right, white client? Am I am I am I describing it correctly? That like at least in that one since you highlighted it was just like spec checks just not catching that there's a missing field element.

Yeah, I think that that I think that's the that's the issue on that specific one. I'm not sure if there's other classes of issues that spec doesn't catch, right? There's kind of a lot going on there. You know, there's the compilation of the various YAML files into open RPD into a single file and then conversion of that or you know creating the open RPC file of all of those um all those methods and schemas. So there's this assembly phase which could have something problematic in it. Then there's the uh trying to

like parse and read the individual schemas from that assembled thing and then there's the trying to validate it against a specific JSON value that's coming in a test. So there's a a lot of point and you know then verifying the schema has like very specific schemas that it can follow or not follow. So there's a lot of moving parts that I'm not sure exactly which parts could be having problems with it. Yeah, and that I've start I've started looking at that, but I have, like I said, I haven't gotten very deeply into it yet. Um, so that's on my to-do list.

Um, just out of curiosity, does Spect Check have its own repo? Is this another project we should maybe keep an eye on during these calls and uh address open issues and PRs and things like that? It's in the repo RPC test, Jim. Cool. Thank you. I've Okay. Yeah, I remember seeing this now. All right. Nice. I'll um add that to the pre-work for these calls to make sure that we're keeping an eye on that. Sorry, I have something to say.

Go ahead. Um, so we looked into this I notic that for some reason the test runs after like it's supposed to check on the PR that that's been opened. It doesn't run on it. It checks on the previous state of the that's how it's been. The issue with um the it simulate issue was because block state called it has like a bad response which turns into a a slice that returns a JSON array in the result. So now we having like um a single object. You're supposed to have a

single object but we having like an array. So that was what the issue that that was like the issue from the it site but when I brought it up to ma they noticed that it wasn't checking on the current PR that was open it was on the previous state of the repo. I don't make sense. Well good catch then. Um I guess we'll have to take a look at the GitHub actions to investigate that. Huh. Yeah. I mean, I'm I'm looking at the steps now and it looks like it. Yeah, I can I can look at that again cuz it it's supposed to run on every if it's not checking out the right I don't know.

I'll have to look at that a little bit. Cool. Thanks, Mercy. All right, speaking of PRs, uh we have a number of PRs on their agenda here uh that have kind of been sitting there for a little bit. Overall, we have a lot of open PRs, I think, in this repo. Um, I don't know how many. It's too many. I'd love to hear thoughts from people on that. I don't know how old is too old. Uh, I'd love to hear thoughts on that as well. Um, folks are going to start showing up to these calls and advocating for specific RPCs that they care about and that uh they want us

to include. We should be prepared for that. Um and we should also have some sort of mechanism, not mechanism, but we should just have some sort of habits of of making sure that the PRs that are open get regular feedback uh so community members have an idea of where they are in our process. Um so I guess uh generally anybody have any thoughts on that before we start picking apart individual PRs? Yeah, I think I've said this before, but until we get spec check working consistently, then it's hard to make much progress on the PRs because we don't know if what we're merging is actually working and correct.

So, it feels a little bit like this is a blocker for making serious progress on the open PRs. And you don't and you don't think that there's anything like like what would be the second issue that you would want resolved after that if we can just handwave away the spec check thing. I think that there are a lot of PRs that can be closed or PRs that are easy merges that maybe don't necessarily affect the spec.

So if we're trying to get that number down, there are things that we can do. I just think that there's quite a few fix PRs and we don't even know if the fix is working. And there's also a lot of PRs of end points that people are proposing that we can't really make a decision on because it's not our decision. It's like the all court dev's decision. And so the question is like should we just keep those around forever? Should we close them at some point? I think if they're a year old, it's probably fine to close. Okay, that's that's good. That's good.

So, after we get spec check uh corrected, integrated with CI/CD, we have a better sense of which of these PRs are actually failing or passing, we can triage the things that are not uh requiring ACD review. And yeah, I can imagine that reduces the the back quite a bit. All right, sounds like a plan. So, in light of that, should we not talk about open PRs until spec check stuff is uh is fixed?

I mean, personally, I'm going just say like I don't know how long it's gonna take me or whoever to to get all that ironed out. I mean like to at least not I I know it's more work a little bit but I mean I think it's fruitful to at least have these conversations otherwise we're just going to get bogged down by oh a code blocker keeps us from at least coming to an agreement like you know we can comment on PRs like you know like the two that you have listed like let's talk through those everyone's on board with those we can at least like add a label to them on the repo saying hey these are merge ready so that as soon as spec soon as you know collective effort gets spec checked to the point where we're satisfied that it's working correctly or some equivalent replacement

and we can just merge those PRs. Like otherwise, I feel like we're it's the same problem that happens with ACD. People just get bogged down because like the the error codes like that's a valuable thing that should get done and that's partially already done, you know? I mean, okay, anyone else? Another quick unrelated question for the building the Gatsby docs. What version of node do we need?

You can use any of the latest beyond 20 um works. So you could use like 22 24. Okay. So like all of that is fixed like because it was in a bad state before and then the update I did about four or five months ago. That is that is a hot mic next to an impressive keyboard. Thank you.

All right. Okay. So, um, cool. Shall we start talking about the PRs then? We have two that are on the agenda here. The first one is interesting. Adding time stamps to log receipts. It looks like GU has already adopted this. I recall someone adding this, but that's all to remember. So in theory that that means that GU is ahead of the RPC spec on this one and so we need to catch up to them so we can

fill tests. Am I am I conjecturing here? Is this an accurate problem statement? I don't really remember what happened when we brought it up on ACD. I kind of recalled people were in favor, but we would likely want to just make sure that that was the case.

And if so, hit the merge button. But there are also no tests for this. So someone needs to add tests. Sorry, which one is that lost? It's the ad block time stamp to log PR 639.

Okay. Okay. But yeah, we it looks like G did merge this. Okay. Once we get tests at least to cover this, then uh we can put it on an ACD e agenda for approval. I think it was put on ACD agenda and we just need to go look at the recording to double check that it was accepted.

Okay, I can take that as an action item. I'll go dig through the archives and see if it's already been sorted. Okay. Uh, ready to talk about error codes? There's an interesting issue posted here. It's issue 658. Uh, this was presented on a prior RPC standards call. Uh, which I'm sure there's a recording of somewhere. Uh, unclear as to what proposed next actions we should pursue.

Yeah. Um, hi. I can uh go over what happened uh in the last two weeks. Uh we had a couple of sync uh syncs with uh Zane and Mercy and um um we also reviewed community feedback from Mercy. She put together document uh that was helpful. Um so the outcome is we are kind of aligned. Uh Mercy, please keep me honest. Uh we think it looks good. There's just one more thing I need to do. Uh I uh after talking to Zayn uh last week, we are planning to add ranges um to reserve the error codes that is uh still pending. Uh but once that's done, I think it'll be in a good shape. Um

there's one more thing that I wanted to bring up was um after the docu changes are merged, I would be able to test this out and um keep it ready probably by next meeting so we can make an action item out then. Thank you, Simpson. Of course. And uh yeah of of course any more feedback uh really happy to get and take a look at it. But I think uh it is actually in a decent state if you want to get merged I just need to clean up the PR a little bit make it more relevant and uh add the ranges properly.

Uh and then once that's merged I can start working on the test and uh you know downstreaming it to hive test if needed. Uh whatever works. Very cool. Okay. All right. Well, that's it that for our agenda. Does anybody have any new business? The floor is open. Hey, Justin. Bastion from Alchemy.

Sorry, I I joined slightly late. Um Oh, hey. Hey, I I've been looking at the recordings, but I never had the chance to to make this time. So, I'm I'm glad I could join. Thanks for all the work you guys are doing. Um I I plan on joining the future ones, by the way. I think this is like super helpful to kind of uh help on our end kind of follow up with what's going on on the standard side. Um did you have a chance to talk about the the time stamp and what was blocking us there in terms of merging it into the execution API? If you had, that's only on me because I joined uh 10 minutes late and I'm happy to watch the recording. We we did talk about it. You're specifically referring to adding the time sense to the log receipts, correct?

Yeah, that's correct. Yeah. Yeah. And that's already been that's already been merged into GE, so it's kind of sort of available there. What's waiting on us is we need to add some tests around it because it's really just kind of yoloed in there. And then we also have some CI/CD issues that we want to shore up before we start pulling in uh PRs more aggressively. Um so we we know what the clear next actions are there and it's it's pretty close to the top of the list for next things to be worked on. Nice. That's great. Maybe a call out and I'm sure you'll uh the latest release of GU the time step itself got converted to was hex in encoded. So just something to keep in mind as you add the test.

It basically when it got shipped like two weeks ago it was b just a time stamp um and now it's hex encoded as of I think four or five days ago the the whatever whenever the latest release of guest was shipped. So uh just yeah something to keep in mind. Yeah, it was fixed in 1.16.1 which was released last week. So someone fills test it should come through as hex Sweet. Yeah, that works. I was just wondering if we if we had been writing the test base assuming it'd be just a Unix or just a a number um that test would probably break right now or most certainly would break.

Yeah, it wouldn't be able to fill it. Interesting. Do we have opinions on uh why are you using hex there? Um I actually wasn't involved. I mean I I was involved in the blog time stamp talked to Cena and the guest team about having it in and they were super receptive about shipping it which was great. In terms of like the format itself I think Matt you might have more context here on this one. Um I I I don't. I think it's more so to have alignment with the other fields that are hex encoded. Yeah, exactly.

Uh in like JavaScript you can only represent you know 62 bits or whatever and so we have always encoded all integers hex because many integers in the protocol can be larger than that and time stamp it's not really much of a concern of it overflowing that that size but for consistency we just encode all integers as hexadimal. Good enough. That makes sense. I actually don't know what Reth does. I mean, they they added it like a while back, that feel. I would need to check what they do, but I think yeah, again, for consistency, hex works fine. So, just something to keep in mind, Justin. I'm not sure who's owning updating the test. I'm also happy to

help here. Um, I'm just need maybe a few pointers. Um, but yeah, again, something to keep in mind. I don't know if anyone right now is owning that, but if you are interested in getting this merged to the repo, I think it wouldn't be too difficult to update these tests. Basically, the way the tests are generated and all this information is in the execution API repo. If you go to I think it's docs, yeah, if you go to No, not docs.

contributors. Um, one second. So there, wait. Uh, man, I don't know. Something got deleted from the main. The making changes. MD file got ma got deleted. There. There we go. Zayn just shared a link. I'm happy to have a look at that. Yeah. So, if you take a look at that, it'll kind of describe basically what you need to do. Since this is yeah the way that the the type of method that this is and the field that's being added it will automatically show up if you just refill the test. So you don't even need to go

in and generate new tests because you're just exposing information about the timestamp that already exists. So if you're able to load the latest version of GE and load the latest version of RPC C test gen and and fill for the methods that are related to the receipt then you will then the diff should just show you that the time block time stamp is added. So, can I say something? Sorry. Got it.

Okay. The the repo you're supposed to go into is the test gen, not exactly this um API because whatever you regenerate from the RPC test gen gets automatically filled to the isiction API. Sorry, was there a question or is that a statement? statement. Okay. Yeah. Okay. Look, I mean that that works for

me. I I'll have a look at the the read me and if not I I can figure it out. If not, reach out. Um, is that the main blocker? Once we have that in, like we basically can merge it in the execution API. Go ahead, Matt. I think that's the main blocker. Sweet. Okay, that works for me. Awesome. Good news. Welcome to the call. Thanks, Justin. Mhm. Anybody else have anything they want to discuss? The floor is yours.

If not, we can give people some time back. So, I want to share the um that I shared on the start one. Yeah. Okay. Do you have specific things that you

need feedback on or are you just waiting for a general review? Mercy, I'm waiting for my clients. I don't know if you can see, but we can Okay, I'll include that on the agenda. That that's outstanding and needs to be looked at. Thank you. Well, if that's all we have, going once,

going twice, we can wrap the call here and see you all on Discord. See you on Discord. Thanks, Justin, for running these. I appreciate it. Sure. Thanks, everyone. Bye.