Vibe Check: Priority, Fairness & Building Workflows from Scratch

okay there we go and we are live hello welcome to another vibe check i'm double checking that all the things are connecting as appropriate so we are live this is vibe check um I'm Melanie. I today have Shinyee Chen and Melissa McGregor who are joining me. Shinyee in particular is one of our software engineers at Temporal and he is going to show us what it's like to build priority and fairness with your workflows and doing that from scratch. And Melissa McGregor is one of my colleagues who has all the expertise around, especially our documentation. And so she's here to help me co-host. So hi, thank you both for joining. And yeah, Shinyee, would you like to just quickly share a little bit about yourself and what you work on and what makes you excited about from a tech perspective? Yeah, sounds good. Hey, everyone. Glad to be here. My name is Xingyi. I joined Temporal three years ago. I'm currently on the Temporal Cloud Growth Team. My team manages the onboarding, offboarding, metering, billing for the Temporal Cloud Platform. And before this, I was at Uber. That's how I actually got to know the you know the previous version of temporal which was called cadence back then was so so popular with them we were used by like hundreds of teams handling very critical workloads so my team used that a little bit and then that's how i got to know about it i was just very excited about temporal as a technology it's just so powerful and it introduced a new paradigm of coding so i'm just like very excited about working as part of this company now That's awesome. And, Melissa, you want to share a little bit about you and your background and what you're working on? Yeah, real quick. So I'm on the docs team. I try my best to make our open source docs as accessible and understandable as possible. Before I worked on the docs, I was an engineer that liked to work on docs. So it's a little bit of serendipity there. That's awesome. Well, so... I'm going to go ahead and have this, you know, Shinnyu, let's dive into showing this example. And by the way, I did confirm we are up and running. So, you know, for those who are out there and watching, we appreciate that you've joined. And if you have any questions, please go ahead and put those in, you know, put those comments out there. We've actually got up on our channel that you can actually see the comments this time. So please feel free to ask questions as we go along. But yeah, Shinnyu, why don't you dive into the example you want to show? Okay, sounds good. Let me share my screen. Let's confirm the screen is up. first i know i've got the i see it and now i'm going to add it to the stage can i add it oh i know why here we go there we go and go to roof and add there we go all right now you see my diagram and then later on i'm going to use my ide to live code something so yeah so today we're going to talk about uh two actually three features right like we're going to talk about how temporal can help you to uh enforce feature uh like ray limit So feature one, we're going to talk about task queue rate limit. And feature two is priority. That's in the title. And then feature three is also in the title. Affairance. So before going into the details or before going into coding, I'm going to explain to you what these features are and why those are useful. I'm going to just use a very simple example of a pizza shop just to make things like uh relatable to our day-to-day experience right so imagine you have a pizza shop right and then to keep some things simple we say you just have one chef right just one chef and then this chef can make one pizza every five minutes right so naturally uh you know you might have some peak hours for your restaurant and uh let's say it's dinner time and an order start to come in right so order one order two By the way, is this screen large enough? Yeah, I think this looks great. Okay, great. Okay, so now you have like a stream, so orders coming in, right? And then that's the point where you have limited number of resources, and then you have a large number of workloads. And then naturally, you want to apply some back pressure and then say, okay, you just have to line up, right, in order of orders coming in. And then the chef would just process one order at a time. So basically, that's, I think. everybody understand that that's just the rate limit feature. They're not going to demonstrate how to implement that using temporal activities. So like Melissa and I both have ordered pizzas and then we got a bunch of other people from the team who want pizzas and the chef can only handle so many pizzas at a time. Yeah, exactly. And then what's going to be more interesting is once you have a more slightly more advanced business model, let's say you have like two classes of members, right? You have like people who are not even a member of your shop. and then they just come in and order pizza. And then you also have a VIP membership. They pay a membership subscription fee, and their orders should be prioritized. So in this case, a naive queue no longer works because someone paid a premium fee, and they probably should get premium processing. So let's say you still have your regular queue, but then someone who is a VIP made a order. In this case, you don't want to put them at the bottom of the queue and then just have them wait. You probably want to say, okay, this one has a priority of one, whereas everything else has priority default, maybe three. In this case, if order one is getting processed, then so be it. You finish that. But then before processing the next regular order, you see, oh, there's a higher priority order, and then you want to prioritize processing that one first. So this is the priority feature that I'm going to show you later on using task queue priorities. Does this make sense? Yes, that definitely makes sense. OK, cool. Now let's move on to another interesting case where fairness becomes useful. So let's say Alice is holding a party, and then she wants to order a lot of pizza, let's say 10. So let me put a dot, dot, dot in here. So she put in like 10 orders. And so all of them are from Alice. And at the same time, you know, you have Bob who just want one pizza. So you have Bob order one, right? So if I just implement this queue, like they all have the same priority. Like none of them is VIP. They're just regular customers. So if I just put Bob's order at the bottom of the queue, then that's not fair right because i'm just serving one customers with all the resources and then the other customer would just like starve out so a fair thing to do is let's say the first line is from alice and second line from bob same thing here instead of dedicating all the resources to all the orders that alice put in uh we should move on to bob after maybe like the first order uh is processed for alice so in this case we call this fairness right like if al is putting a lot of orders they themselves will queue up but it shouldn't uh deprive the ability to serve other customers so this is usually important when your platform is like multi-tenant and your platform of course will have limited resources and you don't want like one customer who putting a large spike of traffic which is like starve out other customers so there's a very nice way to achieve this in temporal. Nice. Cool. All right. So the other three features, any questions? No, I think this sounds great. So you want to show us how this looks in code? Yeah, exactly. All right. And no questions right now, I think, from our audience. But if anybody is watching right now that is interested to have specific details pointed out, drop us a line. Drop us questions. Definitely welcome. Sounds good. All right, I'm going to switch over to my IDE. I just created this empty goaling project. And this is my usual setup. So I have the code and the agent side by side. And I use the voice to text input. I'm going to shift my screen a little bit just so it doesn't block me. Yeah, and I'm curious, have you tried out Fable? Because I know Fable just came out. I haven't. I haven't. But I heard good things about it. So what I heard is it's good, but it's also very costly. So I'm curious what kind of workload people put on that. Because normally, I'm not even using Opus. I'm intentionally using Sonic because I feel it's good enough for my day-to-day, and it's at the right price point. And then you use voice, basically, in terms of being able to just speak directly into speaker commands? Yeah, exactly. Yeah, exactly. So I think voice allows me to put in more input to the agent model. Yeah. It allows me to cover more cases. Which software are you using right now for voice? I'm using fluid voice. So fluid voice is here. Let me try to load it up to see if we can show. Yeah, here. So it might be a little small. I don't know how to make this larger. Oh, that's okay. Yeah. So this one is like uses a local what i like about it is it uses a local model and it is like fast and accurate enough um so i i just don't want to and also it's free so i don't want to pay for it i also don't want my data to be transmitted to some like random uh places so that that's my current choice nice that's really cool like have you noticed it speed up your productivity More than just typing out stuff? I think definitely. I think you can see some stats here. Actually, it claims it's been like 65 hours, and then apparently I've been speaking a lot to computers. It feels a little weird at the very beginning, but you get used to it. And also, the nice thing about Temporal is we work from home, so it's not as weird as speaking to a computer in the office. I think it does allow me, like, to express myself more uh because i'm on typing sometimes i get lazy so my command becomes short to the agent right but when i'm speaking i can just like have this like flow of consciousness and then just talk to agent and agents are smart enough to figure out what i want usually nice all right let's let's do this in action okay great uh so i'm gonna start talking to my terminal so uh i want to build a demo using golang and temporal for the task queue rate limit priority and fairness features i want to break the implementation into three different phases so having one phase dedicated per feature let me reiterate so feature one is task queue rate limit second feature is priority and last feature is fairness and let me give you some documents to take you start yeah so there might be some typo here because of the voice voice input and my accent but usually asian is good enough to figure it out and also i already have the task here fairness document but i'm intentionally also showing this feature from temporal document so i don't know if you know if you go to the temporal docs page there's a button This is my go-to feature whenever I need to search a document. I no longer manually search or use search bar anymore. This feature is so cool. So I'm going to say, can you give me some documentation on task queue, rate limit, fairness, and priority? I'm using Golang as the programming language. It's so cool to see how you use the docs like this. Yeah. um what's cool about it is it it's very comprehensive it not only searches the doc but also the community slack and also there's a community question answer forum so it just like looks at all the resources comprehensively also actually from time to time we actually found some uh github issues uh as a reference as well that's also very useful sometimes it comes back to say okay what you're asking for it has been requested by other members and then it's being recognized by the temporal team or something like that. So I know I'm not the only person looking for a certain feature. Cool. So this is the good document. Let me see. There's a bunch of links. So priority and fairness. Yes, that points me to the exact document I was looking for. And there's a Go SDK priority type. I might just copy paste this entire thing. There's a nice copy button here as well. Let's paste this one in. And also, I just paste the link too. And when we implement this, I want to keep everything simple. Let's use a real-life example of a pizza shop. And I want to have just one activity called Make Pizza. And our model should be really simple, and it is used for demo purposes. So I'd rather just have one activity with a limit of one request per second, maybe wrap that activity with a workflow, and we will call that workflow for the three cases we want to try out. And usually, I don't like having an agent to just one-shot and do everything from my command. So I have some shorthand communication with agents. So AI Rec basically extends to don't do anything in real, just give me a recommendation. So it's like a lightweight of planning mode. I know there's a plan mode in Cloud Code and I don't usually use that. It's just like a little too much talk. You don't. I was going to say you don't think the plan might be useful for what you like to do for your flow? Yeah, so usually I just use my shorthand communication with agent so that I don't have to toggle things back and forth and forget to toggle them back. Sometimes I toggle to plan and forget to toggle back. When you say shorthand, are these hooks? No, those are just literal text in my .md file. So this is under my GitHub repository. But this is slightly outdated. Actually, I start to point this to our internal version of GitHub. But it's pretty much this. Yeah, I basically say when I communicate. Basically, this is a portion that if I find myself saying the same thing over and over again to agent, I just distill them into shorthand communication. And I just send them to this list. That's smart. Yeah, if this gets long, it's probably the point to convert them to skills, but so far it's been working. I like that it's like an intermediate point before just writing the full skill. Yeah, yeah, exactly. It feels a little excessive if I convert this one to a skill. And also, I think for skill, if you want to invoke that, you have to use a slash command, whereas here I just put them into my regular text. So usually I don't read too much into the actual recommendation as long as it looks correct on the surface. Task queue, activity per second, one, this looks right. If you figure out the priority should be between one to five, so that looks good. Fairness, yeah, you have fairness key, blah, blah, blah. One trade-off to decide, priority on the workflow versus activity. And I'm going to say hi to JD. Good to see you as always. He really enjoys your shortcuts also. Okay. Wait, JD. I think I met JD during Replay. Yeah. JD was everywhere at Replay. It was fantastic. He's one of our Constellation members. Yeah. Yeah. I remember talking to him during Replay. Welcome. And actually, I have another shortcut to say AI plan. Do I have it here? I don't know what I have here. Oh, AI plan. Yeah, so this one is a heavier version. I usually do a plan before I execute. So AI Rec is just a very short version of a high-level plan without implementation details. It's a check for me to make sure the agent is on the right track. And then once I'm happy about the overall direction, I do AI plan so that we persist the actual implementation plan in my local file system. so that like sometimes if the plan right now this example is very simple should probably finish within half an hour but let's say if something that should take me days uh this allows me to close my agent or even clear the session and then come back to it uh without worry about like something is getting lost so basically i have some instructions to have agent to break down the implementation phases And then I usually don't read too carefully. I think in the end, still review the code. So like as long as it looks good by and large, you know, I would just let this go. Actually, it comes to ask me a few questions. Where does this code live? Let me check. So this is the right repository. Temporal server setup. Okay, so this one we use. Use temporal CLI local dev. Phase one rate limit. Can I use this worker? Yeah, yeah, yeah. Task to activity. I think that looks correct. OK, so you're doing some level planning. Yeah, yeah. I think I do this more extensively with my actual day-to-day work. I think for this one, it's kind of borderline. If you had to one-shot this, the agent can probably do it. But yeah, when you come to actual production work, I would recommend doing a plan. So right now the agent is currently drafting up for rate limits. Yep. Actually figure out the dynamic config value. I don't know whether all of them are necessary, but fine. Prior to this being live, I know I caught that you found the dynamic config can sometimes trick you up a little bit, right? Yeah. So I think some of the dynamic config for priority event, because this is a new feature. it was not turned on by default in the previous version of Temporal. So if you're watching and if you're using an older version of Temporal CLI, you might have to turn on some of the dynamic configs. But to my knowledge, if you're using the latest version, I think you pretty much don't have to turn on. Maybe you have to turn on one for fairness and that'll be it. Cool. All right. So I think the code is coming in. We can take a look at the code live. while the agent's still coding it up. So make pizza is relatively simple. We just log sleep. Are you able to make that a little bit bigger? Oh, is that? Wait, that font? Yeah, there you go. I thought I changed the font. But OK, good call-up. And you see, everything else is bigger. Yeah. So make pizza, that's our only activity function. So it's really simple. it does nothing except for just log speed 500 milliseconds i'm actually going to comment this run out just to speed things up i think we don't need this um and then we just say pizza started pizza ready and that'd be it let's take like the workflow pizza order workflow oh okay i think this is kind of unnecessary because temporal also defaults to priority three but it it doesn't hurt I have a question for you. What's the importance of the fairness weight here? Yeah, so fairness weight is probably not going to be used in the phase one. In phase one, we only need to talk about the rate limit. But fairness weight is more of an advanced feature. Just so folks know that if you want to, for example, in the previous example in here, we just assume everybody gets a fair share. If Alice putting a lot of order and Bob putting one order, Bob shouldn't wait for all the orders from Alice to finish before getting served. But let's say if you want to have some members to have a slightly higher, more favorable position, maybe they need to have more orders processed within the limited number of resources, you can put a fairness weight on that. So basically, without the fairness wait, it's like an equal split. It's round-robin when you have multiple tenants. But if you put a wait, then let's say if I put more wait on Alice, more order from Alice is going to be processed, while Bob's order will still be executed, but not in a 50-50 split. Okay, that makes sense. Cool. All right. So I think everything compiles. uh let's take a look at the so basically we cover three things right so we have actually there are four things to look at so we look at the make pizza activity there's nothing there basically just log functions uh make pizza workflow basically wraps around that activity nothing fancy either in the worker we have a ray limit of uh yeah so we have a great limit of one activity per second for execution. Yeah, we have execution relimit. So this one enforced our relimit one request per second. And in here, let's see, we're just going to flood the queue. So we know the activity is set to only process one request per second, but we're just flooding that queue with 10. And so if the relimit is working properly, everything should just back up. if it's not working properly everything should just execute immediately so let's see that in action you're starting to like oh go ahead yes so in terminal one i'm starting a local temporal server and let me share that on my screen making this largest there's nothing here i just started the server no workflow and in the second screen i'm going to start a temporal worker so temporal worker is This code in here basically registers the pizza order workflow and pizza making activity. Nothing fancy here. And then last terminal, I'm going to kick off the request, order request. So basically this script, we're going to flood the queue with 10 orders. So many orders. Yeah. All the pizza all the time. Yeah, you can see in here. And I'm going to talk about why they stack up like this in a little bit of time. But you can see, we send in 10 orders. And the activity itself doesn't take any time. And then the only constraint here we have is on the worker. And we have a task queue activity per second to be one. And then if you calculate that, 10 orders, each one takes one second. So overall, it should take 10 seconds. So this is pretty much that. You might notice in the last column here, if everything is back-pressured perfectly, you're going to see 0 second, 1 second, 2 second, all the way to 10 or 11 seconds. Why is that stacking up like this? This is a lot of implementation details. So by default, the task queue is backed up by different partitions within Temporal server. So you have partition one, two, three, four. So by default, you actually have four partitions under the hood. And every time when a request comes in, it's routed to one of the partitions. So each partitions keep track of this rate limit independently. So for example, if you own the surface set this rate limit to be one, each partition actually gets a quarter of it. When you flood the queue with a number of requests, and ideally we'll have even distribution, so each partition independently sees a request coming in, and you're like, OK, this is the first request I'm seeing. Let me allow it. I'm not at the real limit yet. So that's why you see all four of them are executed at the same time, if they all start and finish at the same time. So that's just an implementation detail surfacing of over time, if you're like, average over time, it's still the one square per second is maintained. But that's a caveat. You might temporarily burst through your limits. And first thing is this partition setting is configurable. If you're using temporal, if you're self-serving, you can configure yourself. If you're using Temporal Cloud, Temporal Support can help you with that. But that's not like a perfect story. I think I've heard, I've already talked to the team and then I think they're trying to build a dynamic partitioning, meaning like in our case, we really don't have that much traffic, right? So everything can be technically served by one partition. So imagine like this one, instead of being hard coded to four, it becomes dynamic and you can split and merge partition according to your traffic pattern. So it would be so nice. And if that's implemented, because in our case, the start was just one partition. And then that one partition will have a request per second of one RPS. And then if that's done, then you're going to see a very smooth back off in here. OK, that'll be super cool. Yeah, it's a very highly demanded feature. Yeah. Cool. All right, so let's go back to my Cloud Code terminal. Let's do phase two, let's say. For phase two and phase three, we would still maintain the one request per second activity rate limit just to demonstrate the order back off feature. Because I noticed, I think it didn't do this rate limit in case two and three. I love the verbs that Claude comes up with. Is that clodding? Yeah. By the way, you have control over it. There's a setting that if you want to put your own words, you can. It would just cycle through them. I feel the same, though, in terms of whatever words it's pulling in to say, I'm currently working on it. It brings a little bit of fun. So, Shinye, you've mostly been coding out of Sonnet 4.6. Do you ever switch to some of the higher models based off of the workloads that you're working on? Yeah, depending on what problem I'm solving. And so if I'm dealing with a very, very hard debugging issue. i might switch to opus and now we have fable so i might try that but uh if i know like the general direction and if i just need some coding agent to do manual work or figure out the details and usually just default to sonic nice and just wondering for the task queue activities per second right now it's one but let's say we set it to like three if we sent those 10 requests in how would that work with the higher like rate limit yeah you can you can see uh i think basically you're gonna see three requests executed at the same time um so what just happened let me kill the server as well so that i can start with a clean slate but no such files are actually pizza them oh yeah because i already switched to pizza them uh let's run phase one worker and where's my terminal three yeah so okay i'm already in pizza demo so higher limit will just allow them to be executed faster see 10 orders finishing three seconds so overall like apart from this like short bursts overall i think uh the rate limit is maintained on average okay so let's see phase two is implemented let's take a quick look at what's in here So what do we do? So we send in, okay, so we have a mixture of regular order and VIP order, and we just send them in as a for loop. And I actually want to suggest a change to this because I want to have a clear distinction. What I want to do is I want to flood the queue with regular order and then pause a little bit and then send in VIP order so that I can very clearly show, you know, like the, queue is fully saturated when the VIP order comes in. So I want to propose a change to the phase two script. So I want to split them up into two chunks. I want to flip the queue with regular order. So with the request per second to be one, I can easily saturate the queue. And I want to sleep a little bit and then send in the VIP orders. So that way I can very clearly demonstrate the VIP order can be processed with priority. And also, I don't know if you noticed, I use this line references a lot. So I use this call plugin in my IDE, in my Golan IDE. And then technically it's an environmental, or it's aware of which line I'm at. So if I choose this line, actually on here on the right bottom corner, And you can see it knows I'm in the main.go. It actually knows my line number. But usually, I use a shortcut of Command Option K that basically very quickly populates the line numbers I'm at. And I like that because I can very easily select multiple lines from different files as I'm reading the code. And it just makes it easier to tell Claude what I'm looking at. Yeah, that's a neat little hack. Yeah. Okay, cool. So now we have broken into two chunks. I want to see. Okay. So first chunk. Also, Jatin, I appreciate that you're out there and saying hi, as well as Manu. Thanks for joining y'all. Hey, welcome. Thanks for joining. And then, yeah, now we have like two chunks of orders. Basically, just to reiterate, we send in like 10 regular orders, sleep for two seconds. i'm just going to see for one second and sending a bunch of priority uh vip orders so let's see this in practice give me can you give me the commands to run phase two so control server see like that's one thing that uh claw doesn't do well it's like if i just copy from command line it doesn't handle the line breaks very well my co-worker chandler actually built this very nice tool called cleanup So actually, sometimes I have to copy paste in here. Claude also gives you a copy command. So you can also copy, but sometimes it's harder to copy when you have multiple of them. So yeah, I use this tool all the time. It strips out all those new line characters and all the weirdness, so you can run them very easily. I think at some point, it should just be something you click on, and it can open it to you. All right, let me check my terminal UI. Now, I have a restarted server, so all the previous runs are gone. And let me go to the terminal three, run this phase two priority script. All right, so we have, OK, so I'm going to now refresh for a second. So as you can see, the queue has been flooded with regular order, with three VMT order. Now I refresh again. the vip order you can see they are all processed while the regular orders are still waiting right so that's the priority feature we're talking about you know you don't wait until all the regular order to be processed before processing the higher priority order so that's working as expected any questions before i move on so no i mean oh go ahead i just had a general one for priority so like if you have requests come in at different priority levels, they all get funneled into these virtual queues, right? That's right, yeah. Yeah, so I think you can actually see in here, this is the high-level architecture diagram. And on the surface, you have just one task queue, but Temporal offers five priority levels by default. when you set a priority level actually let's see where that priority level is set it's set in here i said there's a priority key when you invoke connectivity or workflow i haven't tried it on workflow but yeah i think you can also set this on the workflow uh you you set a priority key right this priority key should be a value one of five one means the highest priority five means the lowest priority and then if you don't set anything it becomes to be i think it's three yeah Yeah, exactly. So it defaults to three. I think it defaults to three. And in the back end, basically, you can imagine them as like five different buckets, and they're just dropping things into the bucket. And items from the higher priority bucket will be processed first. Nice. OK. And in the meantime, I got phase three implemented. Let's take a look. Oh, it's already done? Yeah. Yeah, basically. running in the background while we are talking smart okay so now we have two sets of orders one is downtown orders and we have sub suburb orders uh are we treating the suburbs fairly yeah yeah the suburbs just deserve some level of fairness to downtown it might be a little longer of a drive but still and OK, so I'm going to give the same comment, let's say, in here. I actually got a question from JD. Are you using the temporal plugin skills in this demo to build the workflows from scratch? Wondering if we can find that priority feature from those skills. Right, right. Yeah, I think last time when I tried this myself, I did see Claude explicitly use temporal skill. But this one, I actually didn't pay attention in YB. and i haven't checked whether a priority of fairness is in the skill but that's a good point i think if it's not in there we should put it in fair all right you're gonna talk about yeah so i'm gonna give a comment to claude for the purpose of this demo can we do similar to phase two basically we want to flood the queue with downtown orders and then send in the sub of borders and then make sure to have some sleep in the middle so that I can clearly show the queue has been saturated when I send in orders with a different fairness key. And I was watching a YouTuber talking about using voice to text input, and he made a very valid argument that if you're talking, you can also give more signals to the agent because you show a thinking process and it understands your intention better. I don't know how true that is. I don't know. I think logically it makes sense. I don't know how well-trained agents are actually for that regard. But that's one of the reasons why I'm also using voice to text input because I can just talk when I think and hopefully get some good results. OK, in here. Yeah, what's up? That's way more useful, talking to Claude than just talking to yourself in an empty room. I don't know. Sometimes it can be useful. OK, so now we have the similar three steps set up. We have downtown orders, we have one second sleep, and we have sub-orders. So let's see if that works. While you're checking to see if that works, apparently, yes, there is a dedicated references core priority and fairness MD in the temporal developer skill. Great. All right, so restarting the server. the worker actually don't know if i need to restart the worker because we didn't change any but because we restarted the server maybe okay and then trigger phase three awareness make sure they're up and running coming back here refresh nothing is here great that's expected all right so same deal uh see a bunch of downtown orders a bunch of suburb orders and you can see yeah now downhill orders are still queuing up in the queue, but suburb orders are not starving. Yeah, I think that covers all three features. So are you able to give some, well, a couple of questions for you. One, I know we've got each order is its own workflow. Can you give some thoughts around like what's the best practices there and why each order gets to be its own workflow? Yeah, okay. So I think in our example, if I could start an activity directly, I wouldn't even need this workflow. I think that's an upcoming... I want to take the opportunity to also talk about this new feature of standalone activity, which is super cool, right? So if you just want to execute something durably, in this case, it's the mixed pizza, right? Like that thing needs to durably execute. If that fails in the middle, you basically have to retry. And that's the core power that Temporal offers. And then that's wrapped in within this activity. Traditionally, to invoke an activity, you have to invoke that from a workflow. And then so that's just how it is. And then that's why we have a workflow here. And then you can see this workflow isn't doing much. It's just a wrapper around activity. And imagine you have a use case for having a lot of them. And if you're using Temporal Cloud, it's kind of costly. All you need to do is to have this activity, but you have extra workflow bills as well. So Temporal is adding this new feature. It has already launched standalone activities. So actually, I might be able to show you in here. I wish I just did this. Why did I even wrap this with workflow? I could have just done standalone. That's OK. But if I did this, right? you're going to see something showing up here and then that still executes durably. I think one missing feature is to start a standalone activity from a workflow. But yeah, coming back to the original point, I think in this case, if I had to do this all over again, I'd probably just try a standalone activity because that's all we care about. This thing needs to execute durably. Do you want to see if it can quickly switch it over to being a standalone activity? Yeah, we can give it a try. Cool. I love coding. I mean, that's what we're doing. Let's clear the context. Hey, do you know Temporal has a standalone activity feature? Do you want to try it out by invoking this activity as a standalone activity and see if it works? Oh, see, this is our skill, right? Temporal is right there. I love that it's like I successfully loaded the skill. Yeah, I hope we have standard of activity in there though. It is in there. Okay, great. And at the same time, I think I can also trigger that from my UI. I agree with you. I want pizza now too. Same. Random ID. What is task queue? Let me see. What's my task queue? Pizza fairness task queue? Okay, that's fine. activity type. Yeah, I haven't been using this a lot, but let's see if that works. Do I need to set schedule to close time? Actually, I need to start to close timeout. 10 seconds should be enough. Wait, what am I missing? Activity type, it doesn't allow me to start it. More options. I think I have all the required parameters. Wait, oh, I already started. I think the UI just grays out for some reason. I might take a screenshot and give it to the UI. But as you can see here, yeah, make pizza. So yeah, that works. I was not thinking about that one. So you were having to set it up in temporal cloud UI because Because this agent is still working, but I want to take a shortcut because you can also start any workflow activity directly from the UI. So you're showing the other way you could do this was within the UI versus just having the code do it itself. Yeah, exactly. And what's cool about Temporal UI is you can also, I use this feature a lot, start workflow like this one. So if you just want to keep all the same parameters and then start a different workflow, you can actually easily do that i wonder if we have the same feature for stand alone yeah cool we also have that right so start standalone activity like this one and then well in this case it doesn't matter because i don't have any inputs but let's say if i want to start with a different input parameter uh i can do that and nice yeah it's showing up here cool all right and then agent also finished what did that do The build is clean. I see the feature. OK, execute activity. Stand along. OK, create a new starter, a standalone activity with a different main function. And I wonder what happens if I just call run. It'll not work. Start it with 01980p something, something. Oh, here, here. Here we go. But why is that? OK, it didn't start with the correct task queue, I think. It put this into a rate limit task queue, but I don't have work to register there. We can easily fix that by having the correct task queue in here. And then run this again. I'll rerun. Oh, I need a different ID, I think, because the previous one is already running. Great. See? Oh, two is the one I just triggered with the correct task queue. So this one just finished. And then this one is pending. And if I register a worker to this task queue, it will finish. Nice. OK, cool. So you got it. Yeah. Nice. Xineen, before we start to close things out, I think one of the questions that was also in the back of my mind, I know you're using Clawd. Do you ever use something like Codex to review what Clawd worked on? Oh, yeah, I do that sometimes. I think usually I actually haven't used Codex to review. I know that's a very common use case. And then, by the way, Codex built a Clawd plugin exactly for that. Oh, really? Good to know. yeah exactly there's a okay let's look it up claude codex plugin uh i think that's very smart it's just a way to get yourself into your competitors turf but yeah so you can you can you can do this and you can invoke it directly from claude to say hey codex review what call just did um i haven't been using this a lot but i've been delegating a lot of work to codex as well i usually still like to talk to claw to come up with a plan and sometimes after the plan is finished i actually go to codex and say you know codex executed um i think over the last few months codex model has gotten better and actually to the point that i come to like it or like equally with Claude, I think what's keeping me with Claude is just like this plugin. It's surprisingly, that's the only thing. If Codex has this line selector feature, where if I go to a line and I have to press Option Command K, it just auto-populates my terminal with the line references. Interestingly, that's probably the biggest feature that's keeping me with Claude. Interesting. Well, this is all great. I appreciate the fact that you went through all the demonstration that you did. I'm going to do a quick screen share of a couple things myself. Specifically, let me go find, see if I can find the thing that I want to share. Because I probably should have had this already teed up, but I didn't. But basically, I'm going to wrap this up. And while I'm doing that, is there any last things that y'all wanted to cover before we close out? Nothing left for me. Oh, I can do a quick shout out for a feature we have in public preview right now, workflow streams. You should check it out if you need to do any type of like status, like syncs with payments or showing people. how their order is going through a pipeline of some sort. Right now we have it in Python. TypeScript is coming soon and the other SDKs will follow. Perfect. And I appreciate you giving that shout out while I am getting there. This is what I want to show you what I want. Perfect. And then today, Shinye, I appreciate it again. You went through basically priority and fairness for those who want to check out more about this. And also, Malisha, correct me if I'm wrong, you are basically the author behind these docs, correct? Yep. And of course, the product team and a bunch of engineers and everybody else. Not just a one person band, but still. So if you have any questions or have anything you want to dive into more, you can definitely check that out. You also heard us talk about the fact that Temporal Skills also includes this. So you can just load up Temporal Skills onto your various code. code partners. We have a webinar that's going to be going on tomorrow at 9am. And if you want to find out more about that, you should check it out. They are going to get into serverless and serverless workers in temporal with our own Lane and Josh, who will dive into that. So, you know, come. join, learn more about serverless. If you want to find out about more with Temporal, we've got our cookbook. We've also got our GitHub repo that you can get access to and use Temporal. I will be at Databricks Data and AI Summit next week. So if you're there, please come say hi. And last but not least, next week, we will have another vibe check. And we will have Elizabeth Fuentes Leone, who's going to be here talking about harnesses. And specifically, she's going to dive into the AWS Bedrock agent core. Shubham and I will be co-hosting together and we'll be talking with Elizabeth and we're looking forward to it. So please join us. And thanks everybody for coming out. Really appreciated those who joined the live stream and both on YouTube and on LinkedIn. Xinyi, thank you for doing the demo. Milisha, thank you for being my co-host. Yeah, and JD and Jatin and you know with all those uh madhu thank you all for joining and asking great questions um it was good to see everybody uh yeah have a good rest of your day and we'll see you next time

In this episode, Melanie was joined by Xinyi Chen, a software engineer on Temporal's Cloud Growth team, and co-host Melissa McGregor from Temporal's docs team and author of the priority and fairness docs. Xinyi built priority and fairness into Temporal workflows from scratch, using a pizza shop with a single chef to make the concepts concrete before moving into live coding.
Topics covered:

Rate limiting, priority, and fairness as task queue features, explained with a pizza shop analogy
Building the workflow from scratch live in an IDE with Claude and the Temporal Skill loaded
Running the logic as a standalone activity
Starting workflows and activities directly from the Temporal Cloud UI
Workflow streams, now in public preview for Python with TypeScript coming soon

Resources:

Task queue priority and fairness docs: https://docs.temporal.io/develop/task-queue-priority-fairness
Temporal AI cookbook: https://docs.temporal.io/ai-cookbook
Temporal on GitHub: https://github.com/temporalio
Databricks Data + AI Summit: https://www.databricks.com/dataaisummit

What feature would you want to see built from scratch next? Drop your questions and ideas in the comments below.
---

Temporal is the simple, scalable, open source way to write and run reliable cloud applications. 

Learn more
Blog: https://temporal.io/blog
How Temporal Works: https://temporal.io/how-temporal-works
Community Slack: https://temporal.io/slack

Developer resources
Docs: https://docs.temporal.io
Courses: https://learn.temporal.io/courses
Support forum: https://community.temporal.io