runAfter(0, ... timing
Hey! Im using runAfter to schedule a long-running operation (internal mutation) after a particular mutation is invoked (through an http api endpoint). What im seeing is that runAfter seems to be:
1. executing serially for all the invocations - ie im seeing the actions in runAfter being executed one after the other, never at the same time.
2. there is a significant delay between when i call runAfter(0, ..) and when the internal mutation gets executed.
Im trying to understand what my expectations should be here. What is the timing and the mechanics of runAfter ?
7 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
hi -- cloud product, right? not self hosted?
also, you say the long-running function is an internalMutation. is that right? typically that would be an internalAction
cloud product - yes
right - its a mutation that happens to take roughly 10 seconds on average. it goes through 250 elements one by one and updates them.
Not sure if this is what you're seeing, but everything scheduled in a mutation will not be started until after the mutation commits. So if each mutation schedules the next one, they'll run serially.
Have you considered doing a Promise.all on reading / updating the elements btw? I'm surprised that you'd see 10s iterating 250 things, but maybe there's a mix of expensive operations happening under the hood? Or are you using Components like aggregate?
i have not used promise.all but let me try that.
i realized one of the things that was taking a long time is invoking a function through runMutation instead of just regular function. that sped things up a lot.
the thing thats still unclear to me is that i have a lot of this happening. seems that they are retries but my logic is such that no other process could be touching the same rows..so im not sure whats causing the retires.
Ah yeah, calling things directly is way more efficient than doing
ctx.run* when it can be avoided - the latter starts a new isolate container. Retries wouldn't surface like that in the dashboard, so I'm guessing that somehow you're calling the mutation three times in the same POST request, or one is calling the next.im willing to send you my code but i verified it and double verified it.
the number of invocations varies - sometimes its one sometimes its more than that