 Hello everybody. Good morning. I hate Monday, so honest. Manuel, you're there too? Well, okay. Hey, Tim. Oh, Manuel says he can't hear us. I'll tell him to maybe re-log. Hello, finally. Hello. Sorry. There he is. Yeah, somehow that dialogue, whether I want to join with my computer audio vanished and didn't come back. I can figure out, Jürgen, are you German or English? Your first name is German, your last name is English. Yeah, my heritage is Norwegian, and there's a long story about how our last name came to be, something about immigration and whatnot, so. Okay, thanks for letting me know. Because Manuel speaks German and I lived in Germany for a long time, and I didn't know if we could talk to you in German. No, I wouldn't understand a word I think. Oh, no problem. Sorry, Manuel, I'm taking your spotlight. No, I think we're still leaving some time for people to join. A lot of news for KubeCon North America, right? I think the requirement is on the vacation, so you might join next time. Great. Yeah, let's get started. So community question time. Are there any questions before we start? If not, then our first agenda topic is KubeCon, which is approaching fast, and we have a lot of presence there. So we have booked office hours. Last time we already had these two slots, 45 minutes each. And we discussed a little bit. They are still reschedulable, but I think by now all the slots might have gone. So we have one on Wednesday, 10 a.m. eastern time, and another one on Thursday, 3 p.m. I think it's not that bad. Given that the event starts on Tuesday, people might be in zero day co-located events. And Friday is the last day, so a lot of people cannot pay attention anymore. So having these two slots are really great. Also Wednesday, 10 a.m., that's before the keynote talks, which started noon. And then the Thursday one. Yeah, I chose that because anyways, this is going to be a busy day with all the talks. I have a talk there and so I selected this one as personal preference. Everybody okay with these slots or should we go and look if we find another one? I think there was an email sent today that today's the last day to pick them. So let's just keep them for now to not lose them. I don't know unless there is objection. Okay, about the office hours staffing, I think to me and myself will be there. And then depending on how we, yeah, we should all be there. Why not? Depending on how what we want to put in there. So for KubeCon Europe, everybody who was attending these office hours sort of was expecting something to be presented. There were only a few that I saw. So I joined a few project discussions and a few actually had discussions going on. But mostly it was one way presentation. And yeah, maybe we can redo one of the deep dives that we are currently planning. Maybe we have a new one up by then. Or if anybody wants to present something in the project Pavillon, please feel free to say you have an implementation and do that. I'm taking applications until KubeCon. And the next point is the project boost. So here it would be, I understand a little bit more difficult to place an implementation of our specification because this should not be about products. This is only for our project being CNCF hosted open source project. And we need staffing. I started a table, but I don't even know the times yet. So Tia, do we have any details on the project boost? I don't know. I got an email a couple of days ago and I still need to go through it. Can I send it to you later today? I'm so sorry. I'm slacking on that. But the way I understood it is to say that we don't have to be there the entire time because it's pretty much the whole day. And the way I understood it is we can also just play videos. Like that's why I kind of went this weekend and created some videos. I'll try to create some more over the week. Just not because I feel like, you know, mostly for this because then we can send them links and maybe we can just loop, you know, a couple of videos. And in the hours where nobody can be there, that can be shown, you know, to people interested. Have you been to booths? I've never done that. So this is news for me too. There was a redhead booth, right? No, what I was with redhead last time was similar to what we did for the project office hours. But basically it was just a redhead channel and you can just, it felt weird to me because it's almost like a resume. You have to say I'm a developer and so and so I'm working on this and that and then whoever is interested can ask you questions or ping you and I didn't feel like advertising myself because I'm just not into that. But this project booth it seems that it's more restrictive whereas like I said in the in the project office hours we can say who we are, who we work for, what we're planning to do for this booth. They said specifically we cannot like do any sales pitches or any of that type of deal or they will pretty much kick us out forever. That's why I was kind of like any idea on what we can do except like loop videos and just be there to answer questions. I'm all ears. I think I've only seen one or two booths last time connectivity to the intrado website was really bad so. But I, I saw a video showing like the centerpiece of the web page and that may have changed I've only seen one or two videos but I think that was a main advertisement for the companies. And they had a Twitter feed going underneath and a button where you could click if you wanted to talk to someone. I think that's all there is. Do you know if there's any chat that we have to stuff. Yeah, they said they will give us the way I understood it there is a specific website for this where you can see chat. I still can't log into it. They said if you cannot go in after two, three days to send out and help emails. So I'm doing that now. And because it does require a pass to cube con, they will give us five passes for our team, since we're doing it. But I just need to log in and then enter in the email addresses for people they're interested in doing this. So they can get a pass just for that. That's as far as I understand I'm still getting there. Sorry. So, yeah, so I need to be able to log in right now they only gave me a pass. And then I need to add five members of this from the team. So if you want to, you know, have the ability you know it's not it's all free I guess if you have time if you don't have time that's all there. But if you want to be able to join in and participate please you know send me private maybe address or something. Okay. Then, I guess we'd be setting up all the links to specification SDKs. So if you loop the videos that we have, I think we should probably ping duck for the recording of our last community call two weeks ago if it's not already on YouTube and cut out our deep dive. If you're okay with that, Timia. Yeah, the only thing I don't know is there is a record button on this thing and ever press it so maybe we never record our meetings I have no. No, it's it's always recording and you need permission by the channel admin or administrator or host, but the host, I think it's dark. So, or the CNCF this is it's always recording the zoom channel. But for for you mean for the office hours are you saying. I don't know for office hours no no sorry to get videos together for our project boost. I was thinking about also using the recording of our last deep dive two weeks ago. Yeah, we can extend you if you wish. The introduction slides I have with it last time. So anybody could present those if they would like to. And yeah, those can be useful too because I also think like I agree with you last time we did this I think a lot of people came in just wanting to learn what this is that we're doing. More so than hearing about some internal discussions, but some specific feature that might be over their head. So having some sort of introduction at the beginning I think is useful. If you guys agree. Yeah. Yeah. And I'm still not done with slides for any of these talks yet. I have a ton of slides and I'll send them to you. Yeah, I wanted to highlight just this one because still the cloud events. Doug and Clemens they are sort of where we came from. Please add them to your schedule. And then we have to me and Ricardo giving a talk on serverless workflow. Here's the link to the sketch you can add it to your calendar and also the serverless working group lets us present serverless workflow again. And yeah, I think that's that's settled right you may you're going to do that with Doug. Yeah, and really nice of a man they don't have to do that but they're not as nice to allow us to talk. Notice this year or this time there will be no practitioner summit. Pretty much it should be. And this would also be talks that we may want to highlight at our project booth. I haven't checked. Okay, do you have any talks at cubecon anything that you want highlighted. No, we don't. Okay, then our next topic is. Oh yeah, I put it here I wasn't sure if we should bring it up. So redhead community central wants to showcase highlight or take an interview on the serverless workflow so we might have additional advertisement there, if possible. That's about it. We do have I didn't copy them over but we do have from our second last community call we had the discussion about the release and when to do that and this is approaching fast so our next community will just wanted to remind that in two weeks we might want to branch out and freeze with what we currently have and then give two weeks for bug fixing proof reading and so on to do the formal release of 1.0. Which brings us back to our current work so pull request this is a big one right this is the open API and I think there was lots of discussion on it. Let me check if you have anything else before we go into the PRs and issues and please let me know. So I think we might even be able to do a decision on this one. There were a few changes within the last 24 hours but I think that was only a small change. How long is this thing. Okay, yeah. It's quite a good discussion I really enjoyed it. So in the meantime, last week Monday we had a call with Alex. It was very interesting. I think everybody was on the call right. Yeah. Okay, I can spare the time. So how do we go on about this. Do we have an API do we want more time on this. Are we good to take it over as it is now. So, I didn't get a chance to review the latest changes. Can you just give a brief overview. Yeah, yeah, sure. I basically I But to answer my newest first question. No, I think you're gonna needs to we need to come to the agreement. I don't think I can push these changes or we should push the changes without him being okay with it, because he's been very involved in this from the start, I think that was a very good idea is the basic thing is that we have to make a decision and and this decision, I believe is pretty big I think functions right now, not to bring all the last talk back up or an important part to fix for So, in my opinion, this is a little bit holding up the one milestone whatever one I guess release because it's important. One of the changes that had to answer your question is I, I really try to describe exactly that we, we are able to describe everything with our function definition so see if you have service that you want to invoke that you know where he lives, and you have to know about where the runtime needs to go to invoke it you can use the function definitions, but the only thing that we can. We can have you say, confirm that is probably portable across different runtimes as far as the markup goes is the use of open API definition. So we're off loading that part off. We can define custom information within the markup in the function definition specifically we cannot this is specification guaranteed that your workflow definition might work on a different runtime implementation so that's really all I kind of tried in my best English to down and also put provide more examples of how to use the metadata section to have a free form definition that makes more sense for people that they don't they don't want to, or don't have their services exposed to be Now, still the specification allows us we talked about and also open a different PR that we will look at that I think is also very interesting for event based invocation of services we handle that separately. So this only is really the function definitions for services that we know how to invoke specifically not for things triggered by events. Distinction seems a little bit confusing to me. As a user workflow. I feel like I'm invoking something, whether it be event or via event or, or by, you know, an HTTP call. Right, but I'm invoking something and waiting for it to complete and getting a result back in some fashion. So, like, to define those two different ways of invoking something differently is seems confusing to me. Yeah, yeah it doesn't. It's kind of confusing in general because this is not a feature that other markups for workflows like you won't find this in AWS or Google or Alibaba I believe but they're not here to tell me wrong so I can say what I want. Yeah, the difference is is that what we have event definition to describe events they're either consumed or produced, and we can already produce events in transitions at workflow and definitions and things like that. The same approach we're taking for actions where we say look, I want to produce an event but in order to produce an event we need to keep it consistent by just referencing it we reference an event definition in transitions we reference an event definition on the end definition to produce an event so in order to keep it consistent the actions do the same function definition does not mean execution of a service it just means a description of invocation of something that we want to invoke. But the actual action itself will be divided it and from the market perspective, I'm not arguing with you your again I think there could be improvement there in order to make it specific. But I'm just saying like the idea of actually moving that into a function definition itself. That's where I'm kind of like, I don't know about that. Well, so the, maybe. I mean what I had imagined it would be a function that would reference to event like basically look the same as the events. A camera was called in the action section. But, you know, it's still reference to events, it wouldn't be like defining them in mind in the function. Right. And that's a good idea the only thing that I have issue like not to have an issue with but maybe more more I'm asking is, does he really fit in there because sending out an event can really trigger a set of services so he wouldn't be a function definition or a service definition, whereas in a function each of the definitions in the functions array really represent the single service and its operation, whereas triggering an event can actually invoke invocation of 15200 services. And it might not be even services might be other work might be triggering whatever you know he's actually listening for this type of event. It can even trigger an Argo workflow or trigger a pipeline execution in this case. Yeah, so that that is why my confusion is like, if we add that in there are we confusing people as far as what a function definition means. And so we can definitely talk about it I think that's a that's a very good. What you know and I agree in some way maybe finding a way to kind of put this together makes sense. But how you know it's, maybe we can do some examples and talk about it. Yeah, I'd like to explore that I think there's ways to make it. You know, I think, as a as a consumer of a workflow I just want to, whether it's, you know, a whole thin slew of services that listen for that event and respond or it's one thing. I'm still kind of trying to kick off invoke something. Right. And so I don't really want to know the details I just want to know that how to invoke it and what to wait for at the end. Right. So it's, you know, it seems like that's easier for people think about if it just feels like I'm invoking something. I'd love to explore it more. You know, like we can go through some examples maybe just to kick around the idea and that in that issue. Is that what you're thinking. Sorry, I didn't hear the last thing. I think the last thing you said is maybe we can go through some examples and. That's I think the best approach one of the things I found was like once we started actually doing examples and seeing the Jason or the YAML Danny kind of clicks, you know, and say, wow, this is two verbose or. Oh, wow, this makes actually no sense whatsoever and having these types of iterations I think would really help to nail this down to be better than what it is now and I agree it's not perfect, but at the same time is not bad either. So yeah, so let's keep this PR open then what do you think until we or should this discussion about actions be separate. Well, it seems to me like this is a, I mean it seems like we can resolve this PR and then, you know, to do a separate discussion about the actions thing. And, you know, maybe that changes this PR a little bit but it doesn't seem like we should block this PR for that. Thank you and I think also for KubeCon, you know, having like this little bang of a milestone one release I think would be very beneficial. And knowing that yes we're not perfect and yes we've got tons of improvements to make in the near and far future, and it will do it in the in the milestones to come is that something that is okay also you're. I don't like I guess I've never thought about that so I don't know what to. My feedback around that would be, does it need to be 1.0? For example, the questions I am asking myself is what is the in the CNCF community. What is the general perception if you need to do a breaking change from 1.0, right. And then the second question I'm asking myself is like should it be 1.0 or like another milestone that is less than 1.0. Like, are we what are we trying to convey with 1.0 are we saying we're very stable. You're not going to get much changes to the spec app for this, or are we saying there's going to be still many changes. So I think those are the two questions we need to answer. And they're all valid questions and I get it but the problem we've been around like we have been just accepted what in June or July for sandbox project and. And one of the things maybe that is that I wanted to convey with this is more PR move more than anything. We know that we need a lot of improvement. We have been doing improvements for a long time now but still a lot is to come and and this is where you guys come in and everybody from the community. So the point of improvement continuous improvement is always going to be there. As far as stability goes my question goes back is like, when do we say we're stable at some. If I look at other workflows like what we discussed in last meeting and all the other ones we're already a super set of pretty much everything that that is out there if I'm not mistaken. There is, in my opinion what I wanted to fix is this function definitions to kind of clarify that from the perspective of being a little bit more stable than what we were with some custom definitions before. Another big part of an organ is helping me out with that as well with his issues is the air handling and the retries that section really needs to be improved. And I've been kind of trying to get that done whenever I can but haven't been successful yet to finish. So the only thing for cube calm now is we have to figure out, because we already had talks at last cube calm we were 0.2. Now, if we are still 0.2 that might look a little bit like we're not doing anything or not doing any incremental improvements. Basically, the only thing is question is how do we, how do we show people that we are continuously moving forward. At the same time, keeping this notion that you're saying is hey, are we stable, can we be used, because frankly, we already work, I've been working on two runtimes now for this, both Java based and it works, you know, so what a stable really mean I don't know. I mean, it's more of a decision by our team that I think the perception of anything else. I don't know. No, no, definitely. I get the PR perspective and the need to show that we're making progress. Yeah, that's the question I have is it should it be 0.3 0.5 or straight 1.0 right. It's really clear as long as I can say, you know, that like when we introduced our specification we can say hey, we just released version x point y and I really don't care what it is. Honestly, as long as, as long as there is something that we can say, you know, because the bigger problem also and also manual you know this are 0.2 releases actually in our old GitHub repository. So the current one that we are at, we actually have no releases yet. And that would also help with that where we can actually remove the 0.2 completely, because it really is kind of like, we've done so many improvements after that I don't think it's even relevant that there is no runtime, or actually using that old version. Not remove it but maybe just push it somewhere where it's kind of hidden maybe a little bit, because we don't want people to go to the old repository, you know, just have a release on ours, which before we also only had a release of the specification schemas, but now we also have the Java SDK to go SDK the visual studio code plugin, and all of those places with once we do a release we can say a everything kind of works together everything supports currently this version. And I will move everything again forward to the next one as we improve. So there are several definitions of what a one dot oh release marks. One I found was that people think it's sort of complete in a way that it has all the aspects covered is not like imperfect but in completeness, and that it is usable and I think we are already past this usable so I'm okay with going to higher versions. But it's also different teams and develop different cultures if you take Canadian for example they are still in the zero dot, but they are being used a lot in other projects. So I really think with we, if we do a major release here. That's something where you can then later safely do implementation on SDKs. Of course, until the next major release but for a while this will be the standard being used in implementations. And then whatever the next release brings can be rolled out at a later stage so having this state captured in a major release version. To me it makes sense I personally when I started I had doubts about everything like if states should be the right thing to use you know other projects use like tasks pipelines. They originate from CI CD pipelines and so on there are direct our cyclic graphs and all sorts of things, whether we should really have these states was unclear to me but. And now that we have also covered the how to invoke a function for the first time we have somehow settled on this HTTP binding being something that we would want to see supported. We have the JSON and YAML formats for everything and we have cloud events, not just saying like oh yeah it will be cloud events someday but actually using cloud events in the specification. To me that's pretty good, pretty good state right now. And in addition, you know, with the addition of the SDKs and the Visual Studio Code plug it's all specification based and that's important. You don't have to go out and download some, you know, companies extension in order to use it you download the serverless application extension, you know, and I think we're getting somewhere is just growing the community and actually changing our processes giving the number of people, you know that we have and I hope one day we will, you know, become like where we get like cloud events in a meeting and we have takes like a month to do a single PR I would love that as well you know, and, but it is what it is at this time and we just have to push forward and I think we have the ability with a smaller community and people, you know great people and the others they're joining to really do something about this but yeah please, you know, keep patient with us and just, you know, let's see if we can together move this forward because at the end I think we will all have success some sort of success with my home. Let's see. About this function ref and event ref. Yeah, maybe we can speed things up a little. The one thing is, whether we allow the PR now or keep working on the PR and merge it later. We can merge it now and then make an additional PR on top of it. I'm very much in favor actually of collapsing event ref and function ref into just function ref because the way event ref is specified now with the trigger and result that's a message going out and a message coming in. It's very much like a function call. So in a function call you also only know the function signature, you know what to send out the event specification like the event type also tells you what to send out. So in that case the trigger and making the function call is similar. What you get back is sure in a swagger definition would be defined what you what it carries in the body as your result and here it would be the event type that also declares what you can expect in the result so in a way they're very similar. Also, what I personally sees, maybe I want to treat for for not found as a good case, not as an error. Maybe there is even more than one possible result in here. And having this as a function definition really makes sense to me. It also tidies up the actions right. You only need the function reference and don't have these complicated rules of if there is a function reference in there or an event reference in there. I think those are good points. I think those are good points. It seems like maybe since you wanted me to. You wanted to get my input on the PR, maybe give me a chance to look at that and I can add a comment, you know, I just want to look through it real quick but I'm sure it's I'm sure it's all good we can close that. And then we can move on to, you know, discuss more of this events and function thing in the in the issue for that. Okay, I'm perfectly okay and also if you don't mind, I will need your help with the other issues that we will take you have open especially around the retries and the air handling. I think that will be huge if you can help me out with that. Sure, what do you mean by help like Nothing. I don't expect just a comment. I will do some PRs link him to your issues. General to make sure that that we're going in a good direction with what you because a lot of the stuff you seem to kind of like to know a lot more than me about this. So, you know, just looking over the PRs and telling me, hey, no, you know, I would love to take a look at that. I'll keep an eye out for those and review them as soon as I see them. Thanks. I appreciate integrating the feedback. Anytime. Hey cool, should we go to the first of those issues. Is it in the right order. There's another one. Yeah, that's the issue that we that's the one we already discussed. Yeah, so in the next. Yeah. Jason patch. Ricardo from the standard called Jason patch, which allows you to define commands on how to change the Jason data since all our states that are the workflow that is in Jason. He said it will be a nice thing to use a standard instead of defining some custom modifications of of the data using some other languages which makes sense. We just, I just asked him to maybe provide specific examples to see where he would like to see that fit. And we'll move that forward. I don't know much about Jason patch. The thing that worries me about, like it sounds sounds cool, but hopefully it's not touring complete is it. I don't know much I need to look honestly just wanted to cut it. Yeah, see what his idea was and go from there. One thing I know for sure is that customized can be really a pain, especially using Jason patches, but maybe that's sort of their adoption of the RFC. The RFC sound it's needs a little. You need a little bit of experience with it until you can use it in production but. Yeah. All data we handle workflow data. That we juggle in states. They should all be Jason addressable or don't we have the, also the, the YAML format. The issue itself is always Jason and what he's kind of talking about a run into it and if you guys have just a minute to just playing the issue itself is on the runtime implementations. For example or inject state you have state data. And the inject state gives you a Jason object, which then you have to merge with the state data the same thing is really also on all our data formatting. We get a response from a function call or an event that comes in has its payload, and we have to take this payload and do something with it in order to merge it with the state data itself. Jason patch what it helps in there is right now the way I have to do it. I have to basically use either the the underlying in my case Java Jason API is in order to merge stuff together and it's kind of complicated at times. Jason patch would allow me to simply write instructions like add remove update merge and boom it's done so this really would help the runtime implementations. If we had this or define them and then that's kind of think where he's getting it so really from the market perspective I really see where it fits yet, but that problem does exist if you do guys are running into writing your runtime inputs. We usually use a Jason pass to define where we want the result of a function to end up. Please add delete operations in Jason patch. I mean, they can be used as a script to make more complex modifications of Jason structure. I'm wondering if that is sound in in the markup that we're using so it might blow up our workflow definition a little. Yeah, I mean, let's think about it. Yeah, maybe let's let's wait for Ricardo to maybe give an example of what he thinks how this should be used. Because if I have a Jason patch document within our workflow definition to define which of which data should go where in the in the document that's kind of complicated. But yeah, then the next one uniqueness constraint for workflows. It's a little longer. Would you like to discuss a little bit about this or working go ahead. Yeah. So the background on this is that I think a common feature for people who want to implement workflows is they want kind of a logical single instance, like say I've got a computer resources. I want to repair. I don't want to run that repair job three times. I want to run it once. And if the workflow engine can enforce that uniqueness that makes things easier for people using workflows. And I see a parallel in of this in the event correlation. And it doesn't work well for directly invoked workflows and it doesn't or it doesn't that doesn't exist for directly invoked workflows and it doesn't exist for the like cron scheduled workflows. And so, you know, I was trying to figure out how if there's a way that we could get that uniqueness constraint that we have for event invoked workflows to work for the other two. So maybe that means, I don't know exactly what that means. Because I'm still, you know, getting familiar with the spec. But in my mind, you know, that means something about like changing the way the correlation rules work or making them like pulling that up a level so it applies to all three of those or, you know, it's more of a, hey, this is a really useful feature in a workflow engine and asking, you know, for ideas on how we can, what we could propose. I'll just let you know, even the BPM and guys will don't have both and they've been around for a decade. It's very interesting and I think we should definitely explore it further. If we get it, if we nail it down, I think like you said it is very, very good to have. Because like another thing to look at is like, like AWS, for example, has an additional information you can give to workflows even like restrictions on what region can execute it, or what region can execute to a task within a workflow. And also restrictions based on roles and blah, blah, blah. We don't have that currently so this is important start to start introducing not only the markup as far as the logical execution goes, but also in addition, provide run times to information, because in the end. I'm saying what we have to be concerned of and kind of careful is that we allow users to solve business problems at the end. And I didn't get your, your idea but then then I thought about it and I said being able to execute a workflow only once it's actually a business decision is not a runtime implementation decision. You know, I would have the ability to say hey, I'm writing this Tony be executed once and it might be an important part of the business solution. So definitely something that we need to write. I imagine going from one runtime that does support this uniqueness and going to another I would have to rewrite my workflows to do, you know, potentially do that kind of you constraint on their own in their business logic or something right so it wouldn't, my, my, if one runtime sports and others don't. You know, it's, it, that's vendor walk in right there. Right, which is, you know, I think it's a big part of workflow execution like you're saying. And then addressing the cloud events correlation rules I think it's we if we can go with that approach to define correlation rules maybe between workflows and states within the workflows I think that would maybe that's the right approach right now but yeah let's let's move this forward and add to it as we have ideas. Okay, okay. So maybe I'll, I'll think of some suggestions on ideas and just kind of throw out some ideas and we can go from there or what do you think that on the, on the issue. Okay. We also have the event stage right that sort of waits for an event to trigger the workflow or to consume an event and then we have the ability to kick off an event with anything that is part of the event definitions consumed by the workflow as per the, the workflow event definitions, but one thing I was wondering the correlation token we currently using using that's something that's in any payload that triggers a workflow right and doesn't this the specs say that if that token is the same, we should end up in the same workflow instance. This event and I think your again is looking for like cron job triggered workflow so anything like that doesn't have that doesn't have any event. I think we covered like cloud events allows us to cover that part with correlation on the, on the events and their context properties. But if we're just starting workflow without an event, I think your again is trying to figure out how to correlate these types of workflow instances, especially like what he said with the with the cron job execution. Yeah, yeah, very interesting point indeed. Definitely. Yeah. And the events thing makes it kind of tricky because it's like just moving the correlation rules up a level seems to confuse the events side of it, and the way that use case works now. So I couldn't, I couldn't figure out a good suggestion that worked out real well there. So don't be afraid to suggest something that would even change the spec so far when not looking for backward compatibility if that's the better way or unifying things for the workflow that's it's also an option. Okay. Yeah, okay. I'll try to just kind of propose some ideas and point out where it causes problems with existing stuff and maybe we can run from there. Great. I haven't actually thought about it because I only consider considered the event to get what was the very good, very, very good point. Cool. Then I'll move on to the next one. So retries. Oh yeah, that's a long, that's a long standing thing. Yeah, I just want to put it in there to tell your good I'm looking at this. Don't forget about you. No problem. So overall, but you know, the thing that one of the sections that we really need to approve it, I mean, kind of trying to do it myself but now with your comments it's gotten bigger than what initially is the air handling. This is one section which hasn't gotten a lot of improvements over the last time since we kind of took this project or moved it to start moving it forward. And that's part of it. So just to kind of put it in context. Yeah, one way to look at it from protocol design is also like when you take, for example, the TCP stack for something where you cannot even reach your counterpart the connect failing. So that is a specified response. So to the application level, it looks like it, it's getting a response, even though the call wasn't even made so for functions and error handling what we, we could look at this similarly saying that we do make the function call not being able to locate the function endpoint or instance could be sort of a response to the application that is to our workflow engine. If we want to design it that way. The user can decide whether to use that even as in a good weather case like I before when I mentioned before for not fine not found maybe that's an expected response. So to, yeah, having a non tweeted response which was general exception or means we have default error handling or specified error handling. So yeah, okay. Especially the 404 if you think about workflows needing to be generally when you design workflows they need to be very item potent. And so if I'm deleting resources, 404 is a response I have to handle as success in the delete case. Because I might have already tried to delete and succeeded but I didn't get a I got a network error back instead of a success right. So my next attempt would be a 404 and that should be a success. Why do I have it twice. This is 137 and this 136. They're somewhat similar, both related to similar area. Okay. Are actually, actually these are exactly the same weight. The link twice I'm sorry. No, that's about exponential backup only and I think that came after the max attempts and interval attributes is about how to specify these intervals and if it was one shot time. So to say, yeah, I think how to interpret this with respect to the workflow activation. So yeah, okay, these, these two are ongoing. Okay, wow, that our went fast. We're almost up to the our, nobody else has joined in the meantime. So the issues are ongoing any, any final words anybody want to say anything on this. Should I make any notes on any of the issues. Okay, then let's definitely move on this one the open API spec and correct a few examples or follow up on the PR. Yeah, and that's it. So any other business. No, then thank you very much for your participation. That was really good. And we would have our next one in two weeks where we might also want to decide on a feature freeze and branch out for the next versions release candidate. Should we should we have another call next Monday. Please and let's make the decision because you'll take me a while to do that. You know, it's not like it just happened. Yeah, all of crap going on right now with demos and slides and just everybody else. So anybody in favor or against having it next. Another call in between because our next call would be in two weeks and that's already our second glass before cube con. So the idea is my idea would be to have another another call next Monday. Same time because that seems to work. But if anybody I'm flex I'm very flexible on the timing if you have any preferences we could also move it seems reasonable to me. You know, just so chat wise we can follow up on what we just discussed and next time this time next Monday works for me. Okay, perfect. Thank you very much. Then read you later and see you next Monday. Thanks you guys. Thanks.