Triggering a workflow from the client

[davidoort]

Quite often I find myself creating thin mutation wrappers just so i can trigger a workflow from the client. Is there a smart way to wrap a workflow in a mutation which exposes the workflow args?

I guess the complication arises with the onComplete param...

[ianmacartney]

Can you extract the args validator into an object that you use both for the workflow args and the mutation args?

[davidoort]

If you could give me an example that'd be great. I totally think the mutation and workflow can have the same args, with the exception of the onComplete, which is why I still don't see a way I can completely skip the mutation wrapper

[matiacone]

I'd recommend something like this:

export const startClientWorkflow = authedMutation({
  args: {
    workflowType: literals("syncCrm", "syncCrmUsers", "syncCrmCallNotes"),
  },
  handler: async (ctx, args) => {
    await workflow.start(ctx, internal.workflows[args.workflowType], {
      organizationId: args.organizationId,
    });
  },
})

This pattern gives you a standard "workflow API" that you can call from the FE.

If you need arguments, you can change the "workflow type" arg to an "inputs" object that represents a discriminated union of the differnet workflow args

For example, the client would call:

triggerWorkflow({
  type: "syncCrm"
  crmId: "XYZ",
})

[ianmacartney]

Yeah my comment just meant

const myArgs = { foo: v.string(), ... };

export const myWorkflow = workflow.define({
  args: myArgs,
  handler: ...
});

export const startMyWorkflow = mutation({
  args: myArgs,
  handler: async (ctx, args) => {
    // do auth
    return workflow.start(internal.foo.myWorkflow, args);
  }
});

And now you can easily extend/modify the args in v1.29:
args: myArgs.extend({ extraField: v.string() }).omit("foo")...