Mail not being tenant driven when via request

[chris-ware]

I'm stuck on a problem that has bothered our code base for some time. We have a system that allows for importing Users via XML. The XML request comes in from an external system, so posts all data for every tenant into one. There is code in the import mechanics that determines which of the tenants a user should be added to, but when trying to fire a notification, the email that gets sent is in a wierd state of being half tenant powered, half not. After an email is sent for one tenant, the every email after that is stuck with that tenant's theming and content. I've spent hours on this trying to figure out what needs to be purged or cleared in order to get this working. I had hoped by offsetting the mail to the queue, it would resolve it, but it does only in some instances. All code is executed via the tenant execute method.

For reference, I'm using another spatie package to send the notifications (laravel-welcome-notifications), but this happens with any notification added to an observer during a request where the tenant is changed collection.

[chris-ware]

With further digging, I may have solved this:

Container::getInstance()->forgetInstance(Markdown::class);

There may be a better way to do this, but it seems that this solves the problem exactly as needed.

[chris-ware]

No, spoke to soon. This solves it for standard Mail items, but not Notifications.

[chris-ware]

Looks like this boils down to using Laravel methods to ensure that configs are reapplied, such as:

//Solve Theming
app(Markdown::class)->theme($tenant->theme ?? 'default');
Container::getInstance()->forgetInstance(Markdown::class);

//Solve From
Mail::alwaysFrom(config('mail.from.address'), config('mail.from.name'));

[Orrison]

@chris-ware did you do this flushing from within the task that you switched the mail config?

I am having a similar issue to you and adding these flushes as well as the following do not seem to resolve the issue.

app()->forgetInstance('mail.manager');
app()->forgetInstance(MailMessage::class);
app()->forgetInstance('mail');

[chris-ware]

I created a custom task that is used when tenants are switched, which is where I set up a number of these type of functions, such as additional config changes. There are mechanics baked in to support this, its how the package handles things like queue and such. Take a look at the config for tasks.