CBSubs substitutions sometimes not working in CBSubs Email workflow texts

We have language substitutions for all CBSubs Email workflow texts and they almost always work as expected, sending the English version and the Japanese version. But every once in a while, when CBSubs processes the Email on expiration messages, one of several emails processed will only contain the language strings and not the substitutions. The system processes several of these expiration messages throughout the day and almost all of the are correct. It is only occasionally that we notice one that does not process the language substitutions. It usually seems to happen when a relatively small number of messages are processed, in most cases 3 expiration messages, with 1 of them only containing language strings. It also appears that this is happening only to messages from the Japanese side. For example, at one point yesterday 3 expiration messages were processed at one time: 2 in English and 1 in Japanese. The English ones were fine, but the Japanese mail looked like this:

Subject: WWOOF Japan - DEV - EXPIRED_SUB_WW
Message: EXPIRED_MSG_WW NOTE: This email was automatically generated from WWOOF Japan

However, at other times there are many Japanese versions of this message that DO process correctly.

None of the other CBSubs Email workflow texts have done this. It only seems to be the email on expiration. Perhaps because it is being done automatically instead of being triggered by a specific action by the user?

Is there some way we can prevent our members from being sent these untranslated emails?

That should be impossible as worst case it falls back to using the English translation. Ensure your language string is defined in the Default language plugins language overrides first. Then add it to your Japanese language plugin language overrides. This will guarantee it always outputs. Next be sure you've configured your emails as follows in CBSubs.

Email on expiration
Expiration email subject (subscription active): EXPIRED_SUB_WW
Expiration Email body (subscription active): EXPIRED_MSG_WW

Language strings do not work inline. Do not add anything to the parameter except the language key. Do not add trailing or leading spaces, tabs, etc..

I have checked all of these things. The fact that it works properly 99.9% of the time also supports that all of these things are set correctly.

Strange, I don't know how to go about fixing something that happens completely at random. That'd suggest something is interfering with the language file loading behavior. If this is happening ONLY when emails are trigger via the CRON URL then that'd be something we can investigate further, but I don't know what else to suggest without some more idea of when this is happening exactly.

Does this only happen when emails are mixed? As in a few users are English and a few are Japanese? What if all recipients have Japanese language selected? Wondering if there's a loading issue due to the mixed loading.

If this is happening ONLY when emails are trigger via the CRON URL then that'd be something we can investigate further, but I don't know what else to suggest without some more idea of when this is happening exactly.

Well, we are not currently using the CRON URL for this. It is only triggered by front end and admin access. I will change to "Cron task and admin access (100 max/page)" so that we can use the CRON URL for more regular testing of it.

Does this only happen when emails are mixed? As in a few users are English and a few are Japanese? What if all recipients have Japanese language selected? Wondering if there's a loading issue due to the mixed loading.

So far we have only seen this result when there is a mix of some English and some Japanese expiration mails. And we always get a mix of those 2 languages whenever the mails are sent. We never see a case where it is only mails in just one language.

It might be due to the expiration email being triggered by a user with their language already loaded and it's causing the language switching to fail. I don't really have much of an explanation for why it's only doing this for the expiration emails beyond that since those are typically triggered by a frontend or admin user depending on configure. Please let me know if issue persists after setting up CRON to trigger the expirations.