Workflow Status is Slow

[JacobADevore]

[Was told to make a GitHub issue from my Discord post]

I am noticing quite a bit of delay between a Convex Workflow status being marked as completed and then the last mutation inside of the workflow being completed. Essentially my UI is updating with the last mutation made in the workflow seconds before the Workflow status is marked as completed. In an ideal scenario it would come in at the same time.

More details:
I am triggering a Convex Workflow via a mutation on my React client. From there I will monitor the workflow's status via a custom useQuery that takes in the workflow ID. I am using the name prop to set custom names to update the user on what step they are in along the process. When it comes to the last execution inside of this workflow, it is a mutation to update the database. But the mutation triggers the useQuery of the items that have changed to show on the client before the Toast (useQuery for Workflow status) component shows it's completed. The delay is sometimes greater than a few seconds and not an ideal user experience.

Further notes:
I've also noticed that after every execution inside of a Convex Workflow that there is a state the Workflow goes in before going to the next step, I am assuming this is checking to see if there is a next execution/starting it. To fix this on the client I have even had to store the previous name of the workflow because of this transition so it does not flicker updates between going to the next operation.

Any suggestions on a solution to fix the time delay between the last operation and the workflow status being updated?

From: Ian (ianmacartney)

interesting..
how it currently works is that the workflow is a mutation. when it hits the next step(s) it hasn't done, it schedules that step to happen with the workpool. when the step(s) finish, it schedules the workflow mutation again, which runs to the next step. It's worth considering not having the follow-on mutation be enqueued, but then handling failure is not as straightforward to guarantee.. but if you file a GitHub issue for this I'll keep it in mind.
I also have another idea

[ianmacartney]

1. Is this happening on the Pro or Free tier?
2. What is maxParallelism set to?
3. If you check your scheduled functions dashboard section, is there a backlog of work happening there that might be competing?

[JacobADevore]

1. Think I am on Free but happy to pay for pro and test if applicable
2. Default, but I am only testing on 1 workflow
3. Haven't check but is there a possibility of a backlog when I only ever run one workflow with no scheduled functions running in the background?

This should be easily reproducible if you create a workflow and have multiple steps with some async time between the actions and mutations. Then create a useQuery on the frontend that monitors the workflow by the workflowID

[JacobADevore]

Any update on this @ianmacartney?

[JacobADevore]

Another question I had is about built in progress messages to natively update the status of a workflow along the way as the workflow is being completed. What are your thoughts on something like that?

[ianmacartney]

The best approach to have full control over status is to write to your own table as you go along.
Then you can write success to that table in your final mutation so you have transactional "finished" behavior.

In between functions there will be a delay, as well as on completion. I have ideas for tightening that up so it's very fast, but there will regardless be a delay

I'm considering surfacing more granular info about the status of a workflow but the most powerful / idiomatic / typesafe version of this is to use your own tables.

[JacobADevore]

I was basically doing just that before using workflow, but I didn't want to have to write my own workflow if one existed. A simple status field that we can update along the way should do the trick that way we don't have to update until the delay is elapsed

[ianmacartney]

for status, I could imagine:

• a string
• a number (percent)
• a data structure with more specific types
• maybe with an index to see the workflows by certain kinds of status.

I'm nervous to add support for one kind of status that ends up being a "if you give a mouse a cookie" situation. So I generally prefer to give full control & leverage foreign keys to associate data with component data when possible.

Aside from annoyance / clutter, is there a more fundamental gap you're trying to fill here?

[ninjz]

Wouldn't using the custom name parameter be a good way to handle the status? I'm in the middle of implementing a similar thing. Workflows seems like a good solution but from the sounds of it I have to keep writing the status to the database at each step to show the progress to users.

[ianmacartney]

yeah the custom name is a great place for that - good call. Maybe starting with just that would be enough - not necessarily knowing how many times that one has been done. Would it be ok to only show the "latest" step started? With Promise.all, you could have multiple steps started at once. In which case I could return an array, but would rather return a single string for simplicity / not having to fetch too many records

…

On Thu, Aug 14, 2025 at 10:13 PM Calvin Cheng ***@***.***> wrote: *ninjz* left a comment (get-convex/workflow#74) <#74 (comment)> Wouldn't using the custom name parameter be a good way to handle the status? I'm in the middle of implementing a similar thing. Workflows seems like a good solution but from the sounds of it I have to keep writing the status to the database at each step to show the progress to users. — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQW2V4RVTHHA26SJIFSL3NVT6PAVCNFSM6AAAAACC5KS4USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJQGYZTGOJZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>