Closed waqleh closed 4 months ago
The resolver cache is what's meant to be invalidated. Is there a bug in that?
The "tenant's cache" as in data stored in the cache from within the tenant app isn't meant to be getting invalidated, that wouldn't make sense.
Bug description
According to the documentation, updating and saving a Tenant Model's attributes should invalidate the cache entry for this model when
DomainTenantResolver::$shouldCache
is set totrue
. This expected behavior does not occur when Redis Data Separation is enabled. However, the cache invalidation works correctly if Redis Data Separation is disabled.Temporary Workaround: As a temporary workaround, I created a TenantObserver class that invalidates the cache by using the Redis FLUSHDB command. This approach ensures the cache is cleared; however, it has a significant drawback as it invalidates the cache for all tenants, which is not ideal
Steps to reproduce
cache
Redis DB connection): tenancy config file:database config file:
Set DomainTenantResolver::$shouldCache to true. in \App\Tenancy\TenancyServiceProvider::boot:
DomainTenantResolver
, I noticed that it does not start with the tenant id prefix, so instead of they cache key starting withtenantXapp_cache:..
it starts withapp_database_app_cache:...
redis.prefixed_connection.cache
Expected behavior
When Redis Data Separation is enabled, updating and saving a Tenant Model's attributes should invalidate the cache entry for the model, similar to when Redis Data Separation is disabled.
Laravel version
9.5.2.16
stancl/tenancy version
3.8.4