Customer subscriptions notifications for "upcoming automatic renewal" are scheduled despite this notification type being disabled

[erikgeurts]

Describe the bug

I noticed that:

• when I have "Customer Notification: Automatic renewal notice" disabled in WooCommerce Settings -> Emails
• when I then enable the Customer Notifications feature in WooCommerce Settings -> Subscriptions

the software immediately starts to schedule these notifications anyway.

To Reproduce

See above.

Expected behavior

When the "Customer Notification: Automatic renewal notice" email type is disabled, I expect that they don't get scheduled.

Actual behavior

See above.

Product impact

• Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref

Additional context

I've been chatting with WooCommerce Support (case 9265049) but they appear to have misunderstood the reported issue.

[erikgeurts]

Some extra information I just found:

On our staging site, I observed the same situation, the upcoming expiration emails get scheduled, despite them being disabled.

However, one of the test subscription has a renewal upcoming, and at the time the "upcoming expiration email" was scheduled, it was not actually sent. Instead, in the Order Notes for the subscription it says:

Skipped sending “Customer Notification: Automatic renewal notice”:
– Reminder emails disabled.

While this is a good outcome, it does seem like a waste to schedule something that's not supposed to be sent anyway.

The only reason I can think of why this might be a good idea is if the store admin decides later on that the "Customer Notification: Automatic renewal notice" email should be enabled after all, that would avoid having to add them to the scheduled actions at that time.

[mattallan]

Hey @erikgeurts thanks for raising this concern

the software immediately starts to schedule these notifications anyway.

This is the expected behaviour. As you've discovered, at the time of triggering the scheduled action, we check if the corresponding email is enabled before sending the email.

The only reason I can think of why this might be a good idea is if the store admin decides later on that the "Customer Notification: Automatic renewal notice" email should be enabled after all, that would avoid having to add them to the scheduled actions at that time.

You're absolutely correct! 😄 This was exactly our reasoning.

For stores with a large number of active subscriptions (e.g., 50k-100k), looping over every subscription and scheduling renewal, trial end, or expiry notifications in real time (based on the notification period set in the settings) is a very resource-intensive operation.

To assist with handling this at scale, we use a background processor to calculate and create all of these scheduled action in batches.

The approach we took was to schedule all actions as part of the background process, and then only send emails when the email is enabled.

If we were to go with the other approach and only scheduled actions for emails that were enabled, if a merchant was then to toggle on/off these emails for testing purposes, or decides later to enable a notification, we'd then have to delete all the scheduled actions when the email is disabled, and recalculate and recreate all of these scheduled actions when the email setting was enabled. This could create performance issues.

---

Action Scheduler is very robust and more than capable at handling this level of schedule actions, but I'm curious if you have any concerns with this approach we've taken?

Have you seen a spike in performance as a result?

Instead, in the Order Notes for the subscription it says:

Yeah, we add this order note to tell merchants the reminder email was disabled and not sent.
Maybe we shouldn't add this order note?
From a merchants perspective, I could see how this note may come across as something going wrong, which it didn't.

[erikgeurts]

You wrote:

If we were to go with the other approach and only scheduled actions for emails that were enabled, if a merchant was then to toggle on/off these emails for testing purposes, or decides later to enable a notification, we'd then have to delete all the scheduled actions when the email is disabled, and recalculate and recreate all of these scheduled actions when the email setting was enabled. This could create performance issues.

I understand what you mean, but the approach you've chosen just moves the performance issues to another time and place.

I think this approach is a waste of resources:

• on stores that have large numbers of subscriptions, having a renewal notification email scheduled for every subscription, only to then skip it at the scheduled time because the notification type is disabled, puts load on servers for no benefit whatsoever.
• likewise, logging an order note saying that something did not happen is also useless, causes the database to grow with no real benefits, and is bound to cause confusing because people might see it and think: "why is that disabled?" since it comes across as a problem rather than a helpful thing.

Instead of dealing with the symptoms of having and skipping unneeded scheduled actions, a much more solid approach would be to not schedule them at all. If a store administrator toggles an email type on or off, instead automatically starting the batch process you're referring to, simply notify the admin that (for example) enabling a notification type will trigger a batch process and ask them to confirm they're OK with that.

For the record, you're referring to "scheduling expiry notifications", but that doesn't happen at all. If a subscription is pending cancellation before the notifications are enabled, the software does not schedule an "upcoming expiration notification" email. That only happens if this notification type is already enabled and then the customer cancels their subscription.

[mattallan]

For the record, you're referring to "scheduling expiry notifications", but that doesn't happen at all. If a subscription is pending cancellation before the notifications are enabled, the software does not schedule an "upcoming expiration notification" email. That only happens if this notification type is already enabled and then the customer cancels their subscription.

@erikgeurts I appreciate you reporting this. I've confirm this is a bug and will get it fixed up!

---

the approach you've chosen just moves the performance issues to another time and place.

I understand your concern, but what performance issues are you seeing?

Scheduling 1-3 light-weight scheduled actions per subscription, even for our largest subscription stores, shouldn't be introducing performance concerns from your server or action schedulers perspective. The main things to be concerned about with AS performance is long-running actions that can clog up/slow down your queue.

Is there something else regarding Action Scheduler performance that you're concerned about? Maybe I can help clear any concerns you have 😃

I think this approach is a waste of resources
...
Instead of dealing with the symptoms of having and skipping unneeded scheduled actions, a much more solid approach would be to not schedule them at all.

Let me give you an example of where we've been doing something similar already with Subscriptions for many years.

When a subscription has a trial end date, we schedule a woocommerce_scheduled_subscription_trial_end action to be triggered at the end of the trial period. We have no need for this hook and have no functional code within Subscriptions attached to this scheduled action.

Other extensions and integrations (i.e. like WooCommerce Memberships) have found their own use for this hook and have attached logic/functionality specific to their needs.

Thinking along those same lines, you can think of the customer emails and the scheduled actions as two separate features:

1. Scheduled actions for upcoming subscription events

This feature handles everything to do with scheduling actions which get triggered before each subscription event (i.e. before trial end or before renewal etc). These hooks provide a way for plugin developers and merchants to attach their own logic to these events.

Say a merchant wants to send an SMS to their customer before their renewal, they could keep the email disabled and attach their own "send SMS" logic to this hook.

Say a plugin needs to send of a request to an external supplier/system ahead of a subscription renewal, these hooks give them that flexibility.

Without this approach, merchants would need to purchase other extensions to get this functionality, but as the owners of the subscriptions billing cycle, it makes sense for this to be built into our extension.

2. Customer notification emails

These customer notification emails provide merchants with a built-in use for these new hooks. Merchants can choose to enable or disable them separately to the scheduled actions being triggered.

---

In order to move this issue forward, here are some changes I'm proposing we get shipped in the next release:

• Fix the issue you found with our batch processor not creating expiration notifications for subscriptions with the pending cancellation status.
• Investigate further performance improvements to make sure we're exiting immediately if the email is disabled
• Prevent adding unnecessary/unhelpful order notes
  • If the email is disabled, or the subscription period is too short to send a reminder email, don't add an order note that will only confuse the merchant.
  • If WCS_DEBUG is set in wp-config.php keep this functionality for debugging purposes.
• Allow developers to filter get_valid_notifications()
  • This will allow you filter the list of notifications that we schedule actions for.
  • By default, we schedule actions based on the dates set on the subscription, but this filter will allow you to add/remove any notification types based on other criteria (like emails being enabled).

Let me know your thoughts on the above!

Note

Using this filter opens up other potential issues because enabling/disabling emails would not trigger our background processor to batch create/delete scheduled actions. At the moment this is triggered by merchants changing the Reminder Timing in WooCommerce > Settings > Subscriptions.
If this filter is used, the developer may need to also separately kick-off the background processor, or worst case the scheduled actions will be created/updated automatically when the subscription is next updated.

[erikgeurts]

I'm not experiencing performance issues in this regard, I was mainly referring to these stores with large numbers of subscriptions you mentioned, where adding even one extra bit of functionality would cause a significant increase in the use of their available resources. Mainly, of course, in such cases where all renewals are synced to a specific date and time of the month, for example all monthly renewals happening on the first of the month at 3AM.

Thanks for confirming that there is a bug with the scheduled expiration notifications.

[mattallan]

Hey again @erikgeurts, I've been thinking about this problem a bit more.

We haven't had any feature requests for this yet but I can see a situation where merchants want more flexibility around setting different reminder timings for the individual notifications, i.e. send a reminder 2 days before trial end, but 1 week before renewal dates.

If we were to explore this option, it would be simple for us to expand this and allow merchants to also disable these individual notifications.

Ignoring the bad UI, here's a quick mock up of what I was thinking:

🤔

[erikgeurts]

I think that's actually a very good idea, but I'd prefer it if those settings were on the customization pages for the individual emails, right along where you enable/disable them with the existing checkbox and where you can customize the title, heading, and so on.

However, for the time being I'd suggest focusing on fixing the bug with the expiration notification mail, and optimizing the scheduling of disabled notification types (i.e not scheduling them at all).

[erikgeurts]

For the record, you're referring to "scheduling expiry notifications", but that doesn't happen at all. If a subscription is pending cancellation before the notifications are enabled, the software does not schedule an "upcoming expiration notification" email. That only happens if this notification type is already enabled and then the customer cancels their subscription.

@erikgeurts I appreciate you reporting this. I've confirm this is a bug and will get it fixed up!

In one of several stores I manage, I noticed that the upcoming expiration emails got scheduled after all. According to the log entry in the action scheduler, this happened at a date and time I could not possible have been awake and triggered it manually, so it must have been something that was handled by WooCommerce after all. Perhaps there's a daily or frequent maintenance process that schedules things that should have been scheduled but weren't?

[mattallan]

In one of several stores I manage, I noticed that the upcoming expiration emails got scheduled after all.

If I'm understanding your case correctly, this is expected. There are two methods we use to schedule these notification actions in Action Scheduler:

1. Batch processor - When the notification feature is enabled or the reminder timing setting is updated, we use a batch processor to delete and reschedule all of notification actions for every subscription
2. Individual subscription updates - When a single subscription's date or status is updated, we update/reschedule all notification actions for this single subscription.

I suspect this subscription's date or status changed which caused us to schedule the missing upcoming expiration scheduled action.

The bug is specifically with the batch processor not scheduling these notifications for subscriptions with pending-cancel status, however, the individual subscription update process will schedule them.