AsyncAPI Community, 8 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AsyncAPI SIG meeting 50 (June 8, 2021)

Description

This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #50.

https://github.com/asyncapi/community/issues/30

Chat:
00:11:51 Fran Méndez: https://github.com/asyncapi/spec/issues/513
00:13:34 Fran Méndez: https://github.com/asyncapi/community/issues/30
00:20:04 Fran Méndez: https://github.com/asyncapi/bindings/tree/master/kafka
00:23:46 Sergio Moya: Makes totally sense
00:28:09 arjungarg: Sorry, need to leave. Something came up
00:30:10 Sergio Moya: Http, kafka has headers. What else?
00:30:43 Jonas Lagoni: Nats :D
00:30:50 Jonas Lagoni: Others as well I bet
00:30:53 Fran Méndez: Mostly all of them, except WS?
00:31:12 Sergio Moya: Noice, then it is not too early to assume
00:36:42 Sergio Moya: Binding could use the one specified in the correlationId field but always open to be overridden
00:39:19 Sergio Moya: Folks, i need to log out as have an appointment. I love Gerald’s topic so i will like to check next issues you create
00:39:23 Sergio Moya: See u
00:47:02 Fran Méndez: https://github.com/asyncapi/spec/blob/master/CONTRIBUTING.md
00:49:08 Jonas Lagoni: https://github.com/asyncapi/bindings/commit/124c2112b55cdcb89b03014e811cd0de7c1abb42
00:50:22 Fran Méndez: https://github.com/asyncapi/asyncapi-node/blob/master/schemas/2.0.0.json
00:50:45 Jonas Lagoni: https://github.com/asyncapi/asyncapi-node/blob/dc0fce3db8392581a2528e083228852a8cd7893e/schemas/2.0.0.json#L754
00:55:15 Maciej Urbańczyk: https://github.com/asyncapi/spec/issues/507

A

A

So welcome to another passing api meeting. I'm not okay,.

A

So he's on holidays and um I have no idea what's on the agenda as usual, so let me just check what is it? Oh, I see cool, so I see that gerald. You have something there, but as always, that's for those who have to leave the meeting early if there's something that you want to bring bring on like a question or something um feel free to.

A

B

I'd certainly be interested to hear about the 2-1 release. What the current plan is when when will it be released? uh How is it going to be decided or when is it going to be decided? What's part of that.

A

Good question, so I we we set up sometime next week, okay tonight, so we can work on this because yeah we're both coming back to work. So I'm I'm here now, but I'm not supposed to be here, I'm an opportunity to leave, as you know, but uh next week I'm coming back to work and he's coming back to work next week as well from holiday. So next week we're gonna we're gonna work on this and decide everything.

A

The plan is that there is no plan we all we only know uh for now is that it's going to be this month, but since it's the first time, there's a lot of uh house housekeeping tasks that we have to do like automating, all the stuff and and yeah. So until when are we accepting things into into the spec into the into this new release?

A

Honestly, I cannot answer this question right now.

C

I will say that.

A

I mean for houses.

D

A

Until the very late uh moment that um we decide that okay, we're ready to to release, then if, if there's something already done at this point in time, we can merge it down, means test it as well right. So so I guess yeah there's I. I know that maybe you're asking, because you have some some pull requests there.

B

A

B

But not not just that. No I'm! I also didn't didn't know what the process is. But now I know.

A

Yeah we're defining the process and the uh since it's the first time we're we're experimenting and experiencing the process itself and we're trying to housekeeping housekeeping the process and yeah we'll make it better on the next release for sure and we'll keep improving our releases and um yeah. So that's all I can say.

B

And and after that two two: um is there a? Is there a release cadence now or is it whenever enough has accumulated.

A

There is a release cadence, there is a uh the next one is in september and uh can't remember, there's a there's, an issue. Let me just find it.

B

Okay, well september is quite soon.

A

Yes, especially that we have summer in the middle, it's quite soon, yeah.

A

A

So there it is, and um the final decision was since nobody argued against it- is june september january april and repeat june september january april. So it's always the same and um so september. We don't know if it's going to be 2.2 or if it's going to be 3.0.

A

It all depends on the content of the release right. So whenever whatever is merged, it's going to be deciding the number of the of the release.

A

I was going to try to push for 3.0 myself, so we can get rid of this publish and subscribe confusion, stuff and reusing channels and everything, but yeah it's pretty soon and somewhere in the middle. So I'm not sure I should be doing that, but but yeah january since far so it's like it's, it's almost like one more month, one more year with this public subscribe thing, so maybe we should be brave there and and try to fix it for september.

A

I don't know this is something we have to decide, but yeah.

A

Is there anything else by the way the agenda is here for those who don't know, look at.

A

It okay, so I think general you maybe want to.

B

Yes, um so let's make this a discussion, it's not that I've prepared a speech and, and will argue my case, but but I just want to explain what uh what I went through um and and and maybe we can establish some common understanding. So I was right. I was writing the binding specification for the any point.

B

Mq message broker nielsoft's position broker and and in doing that I tried to understand the other binding specifications and learn from them and follow their approach and that's something that I don't quite get in how how messages are defined and message. Binding definitions are made.

B

Maybe if I share my screen, but the host has disabled screen.

B

B

That looks better yes,.

B

Right, can you see my screen.

B

It's good so, let's start with the basics and- and please let let me know if, if I'm on the right page here, um so this is the standard spec 200 on the message object and I, but where I'm coming from, is I think that someone who reads an async api document should know essentially what a message looks like that he will send or receive what had what headed will have, what payload it will have etc.

B

So, when I see something like content type here, which is a string then to me that says that an async api document like that one, no, which defines message to be content, type application, json, that's part of the contract, so every message exchanged through that channel is a json message. This is not an example. No, it's part of the contract. There are only json messages supported. Are we in agreement on that.

A

Well, I will say yes, but there's there's something that we're lacking on the spec and is um specifying which ones are like um part of a contract, or this will be like understood as a contract and which ones are informative.

A

So like, for instance, description and summary title are informative. They're, not they're, not part of the contract.

B

A

So yeah, I will say, that's part of the contract, but, to be honest, um some people might think that this will not be part of the contract because it depends on what you have on headers on the on the protocol binding headers right. So.

B

Let's see, okay, that's.

A

B

That's that's an interesting take on it. Yes,.

A

Yes, so maybe we should, we should be cleaning that out like uh or specifying that I'd like like. uh We need to make it clear. Maybe.

B

Okay, yeah, that's certainly one point yeah um so, but to continue along these lines, then, um assuming that, for instance, content type is part of the contract. Then it is fixed to that value here in in the async api document, whereas for headers and payloads, and I'm assuming now for payload that we actually do specify schema object.

B

The contract is the schema, so, for instance, this here says that messages to or from that channel have a header that has a property application instance idea id and I think, that's optional. So in fact, every any single message can have an application instance id application header, and so what we have done here with application instance id mind sensitivity. That is just an example.

B

The contract is the name and type of this header.

B

And I think we're in agreement on that: don't we yeah so, let's move on then to binding objects, because this work this is where I came from. So I looked at, for instance, this one. This is the emqp.

B

It's the operation binding object, but I think the argument is the same: that binding object defines user id as a string or reply to as a string.

B

So when I see a async api document like this one, this says to me that the user id is fixed to stream to guest every message.

B

Must have guessed or or none, I suppose no, but it's not that message. One can have a different user id than message two, because this is fixed to string just like content type in the other example was fixed to string. What do you make of that.

A

So uh yeah, let me just try to find something.

A

You're right and actually I changed it on the kafka binding, but not on the mk by binding. So if you look at it here in the link, I'm sharing.

A

You will find that group id client id on the operation binding or on the message binding.

C

A

You'll find that key, for instance, is not fixed. It's a schema object. It's a json schema object right there. There you can make it fixed by enumerating a single value like in this in the example of key there, that it can only be my key, but if you want you could make it multiple values, a pattern or something right to match your.

B

Father or something got it so you're saying essentially that this binding definition is not a good one.

A

It's not a good one yeah exactly this, I I it happened to me while I was working with kafka and that's why I changed it like. Oh, this, fixed value is not very powerful. uh It should probably be a schema object. I also thought of making it like either a string or a schema object. So.

D

A

Could make to fix easily, but then you know like making things to have like like multiple types, can't remember. The word right so like making things have multiple types can be sometimes confusing.

A

So that's why I decided on the kafka binding to make it only a schema object and which is a json schema and uh with that you could just uh specify either with inum or or with const, which is another listen schema keyword, make it just a fixed value: okay, okay,.

B

A

That's the case or but you still have the ability to make it uh more complex right, so I think we should be updating the amqp.

B

Right so we are in agreement there. That's also the uh the lesson I I took away from looking at this. I think this is just a bad example of a binding specification um and in fact there are others which take the approach that you just mentioned for kafka. For instance, that's the http binding where, where headers are a schema, object um yeah. So, for instance, in that particular case for a message you can say: headers are content type and it can only be json. I think that's exactly what we had just had for kafka, yeah.

A

By the way, on the on, in the case of http, not sure on the message at message level, but I think we should be or I'm gonna be proposing next, that we use open api definitions to uh as a binding right. So not the whole file. Yeah.

B

A

Just uh the the path item object on open api, which is the one that defines get put post, sure right so actually now the path item is is like for us channel for them is path so yeah. So you can have multiple multiple operations there like get put pause so, and so we don't have to define it ourselves and- um and we already have a lot of tooling available and uh we integrate even more with open api right. So.

B

Okay, so yeah, but but my question is not really about http, specifically, but just about the different ways of defining these message. Binding objects now http this this one, particularly here like kafka. Now it takes the schema object approach for headers, um which I think is much better than the other approach, as we just saw for amqp, but it still has a problem. I think, and the problem is that every async api document will come up with the same properties here now, because they are part these are protocol headers.

B

Now they are always the same more or less.

B

And- and so my question is, if I write message: binding objects for different protocols, http jms any point in queue. In my case, I will have a fixed list for a particular version of these properties for for protocol. Headers question is: do we want to somehow allow the the binding specification to contribute such a schema object?

B

Basically, the binding. The binding specification has the schema object for the protocol headers and then every async api document can just refer to that because it knows they are. They are correct.

A

So you may like having a set of pre-defined headers.

B

That's what it comes down to now, because what we see here is async is my async api document, but your async api document will in all likelihood have the same sections here and others know for.

B

For the cash control headers- and things like that now so this can get quite extensive. um If, if this schema object here were part of the binding specification, then your and my sync api document could just refer to that scheme object and it's the end of story.

C

A

In the end, what you're advocating here is for reusability. You want to make it easier to reuse. This chunk of definition is that what you.

B

That is one part of your of my argument. It continues from here now, but that's the first.

A

B

A

Okay, so I I mean I'm all for it like if you, if you can summarize this on the underneath and I'm happy to to review it, and I think it makes total sense uh think about one thing: for those who are new to the project as well.

A

The binding slan is pretty new, as you can see, versions are 0.1.0, so this is like pretty much experimental and it hasn't been attached for a year, some of them for more than a year, so feel free to either right there to keep proposing there and we, let's, let's work on it.

B

But I'm not uh I'm well. I can't promise that I will be able to uh to make that recommendation as a pr. No, but no.

D

B

But I just I just wanted to clarify whether there is a goal at all and then. Secondly, it's a generic topic. No, it's not just for the http binding, because every every protocol will have protocol headers.

A

Yeah so um feel free to open the issue, and even if you don't have time, someone else can jump in and say no no worries. You don't have to uh champion everything you propose. I we understand people have limited times so yeah and actually I'll be happy to jump in at some point. Whenever I have time.

B

A

So so yeah, but.

B

Do you do you see the value in that? Do you see the language.

A

Yeah yeah for me, of course I mean it's already happening somehow on the kafka on the kafka binding, and um it started happening here in the http, but not quite yet, and uh but still re reusability needs to be addressed and we definitely have to to do something here. I.

B

A

The thing the thing with http, for instance, the reason I did it as a schema object. The whole headers of the schema object is that it can contain any any uh any header, any kind of name right. You can write any header name there. Not all protocols define that or not all of them allows you to to put any kind of any kind of header name.

A

So so, but here in the case of http, this is pretty much open like you can send any headers. You want as long as the client understands it.

B

um Yes, but, but I think part of my argument is that how do I know that it's this field here for that binding object that specifies the protocol headers, I mean as a as a human being, I know, but the tool might not know so. The question is: should the spec define a standard way for a message? Binding object to contribute protocol headers, for instance, by saying they must be defined in a field called headers, and it must be a schema object and the default schema object can be found here, not sure.

A

I see the value of what you're saying, but is it like too early for us to come to to to make a compromise here like that? It's going always going to be a headers field on the on every another message: binding object or in every binding object.

A

I don't know, maybe it's.

B

Well, let's, let's maybe take the next two steps and and and see if that changes anything. So I think for http we're clear. No, there are always headers and there's always content type amongst the headers, so I'll I'll submit an issue that describes.

A

Yeah, I think it's the best way because we're just a few here in the call and I'm sure that others will have ideas as well, so the best ways to summarize it. It's fine that we we discuss it here, um but let's not take decisions here on the other meetings.

B

I think okay, so.

A

Others can also check in.

B

um So, to give another example of a message: binding object, uh that's the one for ibm mq and it defines headers as a string, which is a comma separate, at least now I don't know ibm mq sufficiently to know how that is used, but it's a similar but different approach. So I think.

B

It just shows that these binding objects, they all look very different, um so a bit of a bit of guidance. How how they should be defined would be helpful. I think.

A

I think they always gonna call. Maybe you can clarify, I honestly don't know ibm into myself either.

E

um It's been a while, since I've used it as well to be honest, um but I I'll I'll point rich coffin at the issue and see if he cannot send because yeah. I I'm curious what he was thinking of that as well.

B

um And so that brings me to a concrete example and that's the second step in my confusion, this is the correlation id example from the spec.

B

And it defines a message, object here: yeah, which has a name and it uses this correlation id field in in the standard message, object without actually referring to a binding at this stage.

B

But it says the location of the correlation id is message: headers, mqmd, corel id.

D

B

And that works because.

B

A

Probably in the payload.

B

I'm looking for headers, but I don't think there are headers to find.

A

I don't think they're headers here yeah.

B

Yeah so again I don't know mqtt enough, but I think mqmt only works, because this is an mqtt server.

A

um I'm not sure, but just take something into account like whenever. um So whenever there are not headers defined, it doesn't mean that they can. There cannot be headers right. It's just that they're not defined here right. So that means that on runtime you, you should look on the message. Headers and qmd slash control id.

A

You know what I mean so.

B

A

It doesn't mean that you cannot have headers it's just that they're not defined here. I see you know.

B

So I I have two problems with that here is problem. One is: is it desirable that the message definition without the binding uh ties this down to mqtt to a protocol?

B

A

Thought everything protocol specific.

B

Should be in the binding yeah.

A

Now, you're right, yeah, you're, right, you're right, that's a bad example. Yeah.

A

Yeah, it's probably not a good example of what you should be doing. It's definitely valid example.

A

You should you could do it, but it's definitely not the best um example since you're tying everything to a specific protocol, like you said.

B

But I wouldn't know how to do it differently now, if, if in mqtt headers are under the mqmd folder, I think they call it. I mean.

A

Yeah, the the other, I will say the other way to do it is to put this correlation id information on the bindings that.

B

Was my thank you.

A

But uh yeah honestly, like our effort here, was we were trying to. We were trying to unify the correlation and the information that you can find in many protocols into the trunk specification into the core specification.

A

Okay. But I see that because when you, when you find this correlation id information on the bindings, it has no meaning. Usually it has no meaning it's just another another header. But if you put it here it it has semantics right which is like okay. So this value is for correlation ideas, they're found in headers, but but it's a specific header with a specific name and it has a meaning right. It's a correlation.

B

Which I I think is very good no, but the alternative would be that the message binding object contributes. What is the correlation id for this particular protocol? Where is it to be found.

A

Yes, I agree so this. Oh this, this one is going to be a tough one, because that will mean removing something.

B

um And the second part of my issue is this: uh for any point: mq there's a distinction between protocol headers and application headers.

B

They are not the same no for for jms, for instance. I think I can get every header for that for http. Definitely I can get every header through the same api call for any point mq. I must know I'm not looking up a protocol header or an application header, but from this syntax here I can't see whether corel id is a protocol header or an application. Header.

B

And the question is: should it be a goal that this is explicit now, for instance, for gms correlation id is part of the gms packet? It will always be a protocol header for http. It will always be an application header, because http has no standard header for correlation.

A

Id have no opinion here. To be honest, like there's a lot of cases, there are a lot of cases to consider here in the like, you say the case of http.

A

There's no specific, there's no special header for collision ids, it all depends on the product or that you're using right or the or you can define your own name um for other protocols like mqmd, it's a specific one.

A

I don't, I don't even think like for others. For instance, like websocket, we don't even have headers so.

C

A

C

A

Yeah, it's something that I mean. I have no opinion here. I think uh I think this is. This is a subject that we study. We should study more in depth like how how we can make this more, let's say, reusable or compatible across protocols.

B

But my thinking at least is not it's not a simple misunderstanding of how these things are written. You agree that there's something there that's not quite tied down yet.

B

Okay, then I'll submit probably three issues out of that for these three topics and we can take it from there.

A

Yeah thanks man. I think it's the best idea. Definitely because and and maybe and always do it, even if so, don't wait for the calls to uh to ask if you will submit issues or not because maybe during the call, some of us we're not understanding your point or something, and then we may confuse you a little bit more.

A

So I think it's always better to to write down a new suit and then you know and then have the discussion there, because it's easy that during the call we could even confuse you more and then we tell you like no, don't write a uh don't write down the music for that and it turns out that there's a problem there and it will be done. It should be addressed so so yeah go all always go for for the user. First, okay, that's, I think it's better and then on the call.

A

We can discuss the users easy. I think it's good. It always works best, because then people can also prepare and read the issue before the call- and you know I think it's always best, but I mean it's finally, the way but yeah, but.

B

I have opened that issue yesterday, but it kind of confuses the three or.

D

Three topics.

B

Just became a bit clearer in my mind overnight, but now that we've talked it through.

B

I think I can separate the three issues and submit separate ones for.

A

That so that's.

A

Like looking forward to our like multi-protocol and also multi-spec, if you want um future, we need to, we need to clear. We need to clean these things out. Right like we need to make these things easier to grasp and uh and less confusion for sure.

A

So if we're gonna introduce the the usage of open api as an http, binding or graphql, as well as a binding in the future or in other other specs and multi-protocol, then these little things need to be clear and maybe maybe the way is to make a core spec lighter and then put more uh more pressure on the binding side and then over time.

A

If we think that something there's something in common between all the bindings and it's getting repeated across all the bindings, then we may incorporate it to the course back um and remove it from the bindings, but um but yeah right now, there's a there's a mask here: there's a mess. There is a mix of things that we need to clean out for sure.

B

So yeah, let's say it's a bit blurry, I wouldn't say it's a mess.

A

Yeah, it's not a mess, but it's a little bit like this thing. Here is not really clear, so yeah yeah yeah, it's the result of just uh one guy working on the spec.

A

That's what happens when no.

B

More, that's the longer that's.

A

Not anymore likely but yeah, that's a result of this one guy uh doing all the work, and so you go faster, but you can't go farther so and you commit more mistakes because nobody's reviewing your work so yeah so yeah. Definitely we should we should review this together and work on this together.

A

So yeah, I'm happy that you spot this. These issues, that's good right.

A

A

Is there anything else you know maybe.

B

A

No anyone else, nobody wants to say how much you mean for him when he uh watch the recording.

A

No, you don't miss him.

B

We are shy now, I'm disappointed.

A

With all the hard work that he's doing,.

B

Maybe just one point I mean that release that is coming out. I understand this not just as a release of the spec, but of all the tooling in sync, with the spec. Is that right.

A

Yeah, actually one of the things to make your proposal be ready on the last stage are stage three. I think it is um one of the requirements is that you implement it on the on the javascript parser. You implement support for it on the just report, which is no worries, because I've seen your proposals and it's probably just you- you probably don't- have to do anything on the javascript parser only in the json schema definition.

A

This is just adding another binding right, so I don't think you have to do. I think dale added some things yeah.

A

He added some things on the on the json schema file and then went to the to the javascript, parser and updated to to point to the new isis schema file defining the spec. So that's all you have to do probably nothing else, and if you can't do it, we can do it for you, so we can or we can help you do it.

A

So it's fine, but for more let's say complex issues, then you probably have to implement it on the javascript parser and that's uh I mean you or if you can't just say it loud right like to say no.

B

A

B

No, it's fine, I I I can do I'm a developer after all, I just hate javascript. That's all.

D

A

B

I will swallow.

A

B

A

But that's totally fine, if you I mean hate in javascript. It's also validation. If you want so you can just say like hey, I'm not gonna swallow my pride, you write the javascript part and someone else will love javascript and would love to write this part so yeah just it might take some more time because you have.

B

To find someone you will, let me know on the issue when it's time to write this javascript so that I know.

A

uh It's on the contribution guide. It's on the I think, once so one of the steps, let me just find it.

A

One of the stages required to requires it to be implemented on the uh contributing.

C

Yeah so draft, I think it's draft stage two stage two, I see.

A

C

A

Two requires implementation on the javascript parser and the json schema.

B

A

You don't have to do, merge yeah, it's like they don't have to be merged, just pull requests there right and then for accepted.

A

They don't have to be merged, but they have to be ready to be merged. Okay,.

B

Because I have another pr pending as well, which is about assigning channels to servers now, where.

B

For a channel you can say no, it doesn't apply to all the servers. It just applies to one two and three.

A

That might require something on the on the parser like saying like getting all the channels for specific to server or things like this. You know like or or all the servers for a specific channel, yeah.

B

Okay, okay I'll watch out for that, I don't want to uh hijack the meeting.

A

So this is the contribution guide. There is watching.

A

It's on the chat so for those watching the recording is it's in the.

A

C

B

The json schema work is done, isn't it I mean the I saw all of that merged. So every binding object now has json schemata and they are enforced by the parser.

A

B

A

Magic, maybe you know about it uh or janus, because I've been out and I'm not following everything.

F

That specific thing I don't know.

B

Okay, the the chase's schemata had have been merged into the binding spec project into the master branch, so that pr with with all the json scheme, objects that has been merged. So I thought that's the end of the story, but I don't.

F

Know I mean the only thing that's missing now is to actually validate it in the browser in the tooling. I don't think it's used anywhere.

B

ah I see okay yeah makes sense.

A

What is it, I'm totally lost right now.

B

uh The last merge into the master branch on the bindings project edits. Basically, three or four json schema objects for every binding.

B

F

I send a link in chat to the commit well.

C

C

A

A

Oh, so it's in in each folder, it's in each directory. You have adjacent schema, um cool, that's cool.

F

And we're probably missing to update the.

F

Like the main async api, json, schema definition directly include these documents, pretty sure it's not yours.

A

We have one right, we have, we have one, which is the I think right now. It's in the simple node.

A

Which we need to probably.

A

Rename, but we have one, which is this one in the chat we have like the the main, the main stack is defined as json schema. It's not it's not defining everything, because not everything is possible to be defined with this schema right, but yeah as much as we can.

C

F

There, as you can see online, so 154 we're still missing to at the references to each of the bindings, so they're actually used.

A

Yes, exactly so they're empty objects, it's this means like it can be anything yeah and uh which is funny we now I now. I know it can be true through through through instead of empty objects that will work as well so yeah. We need to put there probably link the definitions there, or maybe we should move all these definitions somewhere and now.

D

But I think that better will be at the links inside the code in the power sync type. I mean because you can use the another version of the binding yeah.

A

Oh yeah you're right.

D

Yeah exactly, and it means that we must check in the parser that you use the appropriate version of the binding and then make inside the the code. The reference yes.

F

Then we just use one.

A

Yeah, because that the the main reason to the couple, the spec with the bindings is that bindings need to have another a another release cycle right. We need to iterate faster on the on the bindings than in the spec.

A

So if we reference it from the spec, if we reference them from there, then we're coupling them and as soon as we change it on the main spec, we need to make a new release in the course back. So they need to be the couple. Probably they need to keep being like this, and it's a code level where you specify which binding you're going to use right, which is not a code level. It's on the it's in your you define the version on your document right.

A

That's why we have the binding version filled on the bindings right.

B

Yeah but but at runtime the parser must read the binding version or default it to latest and then look up the correct.

A

Json scheme.

B

A

Exactly lookup or it will be already included on the on the parser right. It will be bundled with the parser, so it doesn't have to make a call to an external url or anything.

A

And that will also allow us to optimize the parser as well. So you only include those bindings that you're going to use right. You don't have to include every every binding.

A

Most people are just going to use one or two bindings, not more.

D

Yeah I created for that in the person, as I remember or in the specification I don't yeah yeah, but I also described this problem for the parser.

D

F

Yeah, but it was more if we had it in the in the puzzle.

F

Reaper because I don't think we have.

A

No, I also can't find.

D

It okay, I will create that. Don't.

D

A

I can't find it if it's not there feel free to create it and or if you find it magic.

D

No, no, we have only in the specification I will create in the parser js yeah. Don't worry, okay,.

C

Okay, oh you found it on this right here.

C

A

A

Oh man, I'm missing a lot of issues.

A

The number of uses that you faults, create and to input requests per day is overwhelming. Sometimes.

A

When when this project was getting started, I was like following everything- and I had time for that and now I just spent like two or three days out and come back and it's like it's impossible to follow, I'm not even trying anymore, it's like as soon as there's something important. They will ping me and that's fine, that's it! I rely on. You completely rely on you, it's like you, you folks know what you're doing so yeah and now you see I I haven't seen.

A

F

Should we close the issue in the spec? Isn't it it's kinda done, but it depends on.

D

F

Think so we can treat.

D

It as the epic for the specification for parser, etc.

D

A

As you wish, I honestly have no contacts here, so I don't know what to suggest. I first have we'll have to read it so yeah.

F

But yeah we can do that.

A

Pull faults? Is there anything.

C

A

Okay, so thanks for joining once again- and I hope this has been productive and uh yeah- let's keep chatting on on slack, see you in two weeks.

B

A

D