Ability to re-send confirmation emails

[vmatekole]

We have a Dockerised deployment of v0.18.2 at the moment jobs for sending-emais and indexing products, consistently fail. There is no mechanism to re-run jobs or resend failed emails. We urgently need a solution to this problem whilst the root cause of failed jobs is unknown.

In general, I would expect jobs to be re-runnable as jobs should be idempotent.

See further details in #737

[Draykee]

Is there an update on this issue? I also think this featue is quite important and easy to implement in the admin-ui.

[michaelbromley]

Hi @Draykee, can you describe how you would like this to work? Both in terms of the UI and also the API if you have any ideas on that?

[Draykee]

1. Add a action in the admin-ui customer list to resend the verification mail.
2. (optional) Add a mutation resendVerification to the shop-api.
   • This mutation accepts an email address as input. In case a user with this email (+ native auth method used) is not verified yet this mutation will resend the verification email (maybe even with a new token).
   • It would also be nice to store the "lastSend" timestamp to prevent a user from spamming this mutation.

[michaelbromley]

I've been thinking a bit more about this and I had an idea that could solve this in a more general way, let's call it "job triggers"

So the idea is to extend the JobQueueService.createQueue() method so that jobs can optionally specify a "trigger". A trigger is a way of invoking that job arbitrarily via the Admin API, and when defined, it would not only allow the job to be triggered through a generic mutation, but would also automatically expose a UI for triggering the job via the Admin UI (probably in the "system" area).

Rough sketch of the API:

this.jobQueue = await this.jobQueueService.createQueue<T>({
  name: 'send-email',
  process: job => {
    return this.emailProcessor.process(job.data);
  },
  trigger: {
    // these are ConfigArgs just like we use with e.g. CollectionFilters
    // or ShippingCalculators. 
    args: {
      emailAddress: {
        type: 'string',
        ui: { component: 'email-address-form-input' }
      },
      emailType: {
        type: 'string',
        ui: { component: 'email-type-selector' }
      }
    },
    addJob: (ctx: RequestContext, args: any): T => {
      // here we use the data from the args to create a 
      // data object that will be passed to `.jobQueue.add()`
    }
  },
});

I'm not yet 100% sure on whether this will work for all types of job. For example, converting the simple args values into the type of data object required to send an email would involve running it through the EmailEventHandlers somehow.

Right now this is just a rough idea but I'd like to explore it further, as it could be a very versatile API for allowing us to easily set up manually-triggerable jobs and get all the UI stuff for free.

This also relates to #1425.

[martijnvdbrug]

Closing this, as the job queue mechanism changed a lot since this issue was introduced. I would also argue that retrying is the responsibility of the jobqueu. You could create a custom JobQueueStrategy to implement custom retry mechanisms.

Feel free to create a new issue with the latest version of Vendure if you think this should be part of the core