Facades act like singletons, which is a problem for queue worker daemons.

[adrianspacely]

Facades behave like singletons in that they resolve once, and each use of the facade is against the same instance. For multitenancy, this is problematic in a queue environment in that:

• A job for tenant 1 uses the facade. The facade instance contains tenant 1's credentials.
• A job for tenant 2 uses the facade. The facade instance from the last job is set and still contains tenant 1's credentials.

I wanted to share this here for anyone that has run into the same problem. Hope it's helpful.

We added this switch tenant task. Each time the tenant is forgotten (switched/unset), we will clear all facade instances in the App namespace including real-time facades:

<?php

namespace App\Tenancy\SwitchTasks;

use Illuminate\Support\Facades\Facade;
use Illuminate\Support\Str;
use Spatie\Multitenancy\Models\Tenant;
use Spatie\Multitenancy\Tasks\SwitchTenantTask;

class ClearFacadeInstancesTask implements SwitchTenantTask
{
    public function makeCurrent(Tenant $tenant): void
    {
        tap($tenant);
    }

    public function forgetCurrent(): void
    {
        $this->clearFacadeInstancesInTheAppNamespace();
    }

    private function clearFacadeInstancesInTheAppNamespace(): void
    {
        // Discovers all facades in the App namespace and clears their resolved instance:
        collect(get_declared_classes())
            ->filter(fn ($className) => is_subclass_of($className, Facade::class))
            ->filter(fn ($className) => Str::startsWith($className, 'App') || Str::startsWith($className, 'Facades\\App'))
            ->each(fn ($className) => $className::clearResolvedInstance(
                $className::getFacadeAccessor()
            ));
    }
}

[masterix21]

Thanks for your share.

[freekmurze]

Thanks for sharing @adrianb93

I'm thinking we should add a page on Facade usage to our docs. I'll take care of this in the next few days.

[freekmurze]

I'm thinking we should add a page on Facade usage to our docs. I'll take care of this in the next few days.

Done!

https://spatie.be/docs/laravel-multitenancy/v2/advanced-usage/using-tenant-specific-facades

[michaelhume]

Hi guys, my apologies if I've missed something obvious - but since the getFacadeAccessor() method is protected, this seems to have an issue as you end up with a BadMethodCallException with message 'Call to undefined method Underlying\Concrete\Class::getFacadeAccessor'

In my case I'm trying to clear the Storage facade when switching tenants.

[edit]
nvm me.. 😊

app('filesystem')->purge();

[mwagena]

I'm thinking we should add a page on Facade usage to our docs. I'll take care of this in the next few days.

Done!

https://spatie.be/docs/laravel-multitenancy/v2/advanced-usage/using-tenant-specific-facades

Hi, I have noticed that there is a typo in the example code, you are referencing to $facade::getFacadeAccessor as a constant instead of a function.

[lsfiege]

Hi! I'm experiencing a similar issue and the fixes proposed here and in the docs didn't work for me.
Currently, I'm experiencing these two issues:

• The Storage facade often does not change the storage_bucket being used by each tenant (Rate failure 2/10)
• The Log facade often "gets lost" the shared context containing only the tenant_slug and other general stuff

For both cases I'm using specific tasks implementing the SwitchTenantTask interface. I'm running out of ideas and have many doubts about solving this strange behavior. Any suggestions?

[masterix21]

Are you using Octane?

[lsfiege]

Are you using Octane?

Hi! No, I'm running a simple LAMP stack and using Horizon to run the queue workers. This happens to me even in the local environment (the first detection was in my production environment). I had to do some dirty work in order to "re-register" the facades using a scoped approach to solve this, but there seems to be something weird and I'm not sure if it's something related to the package itself or the framework