QueueTenancyBootstrapper Tenant Data Change Not Reflected

[mannis17]

Bug description

QueueTenancyBootstrapper will not recognize changes to Tenant Data until tenancy()->initialized is called.

1. Tenant1 job arrives on the queue and is processed
2. Tenant1 attribute data is updated.
3. Tenant1 job arrives on the queue but since tenancy was already intialized the tenant data does not get updated for the currently initialized tenant

Looks to be the result of QueueTenancyBootstrapper::initializeTenancyForQueue code snippet (or setUpJobListener in 3.4.6)

  if (tenancy()->initialized) {
      if (tenant()->getTenantKey() === $tenantId) {
          // Tenancy is already initialized for the tenant (e.g. dispatchNow was used)
          return;
      }
  }

This prevents the tenancy initialization that occurs after this snippet.

Instead of return here what would be the implications of calling tenant()->end() ?

Unsure whether the If statement was only performance related. In the scenario above if Tenant2 job arrives and is processed prior to the 2nd Tenant1 job then when 2nd Tenant1 job is processed tenancy is intialized and correct attribute data is reflected.

Steps to reproduce

1. Send job for Tenant1 to a queue
2. Run Queue worker (and leave running) and output to log the data attribute you will change in point 3 below
3. Edit Tenant1 data attribute
4. Send job for Tenant1 to queue and output the data attirubte in point 3 below 3
5. The old data attribute will appear

Expected behavior

1. Send job for Tenant1 to a queue
2. Run Queue worker (and leave running) and output to log the data attribute you will change in point 3 below
3. Edit Tenant1 data attribute
4. Send job for Tenant1 to queue and output the data attirubte in from point 3
5. The new data attribute will appear

Laravel version

8

stancl/tenancy version

3.4.6 and 3.5.1

[stancl]

Can you show some actual code that reproduces this?

[mannis17]

hmmm, its more a process flow that triggers it. Will take some time to put together a sample project that demonstrates the issue. If you have a an existing project that handles a queue if you output the tenant data that was changed in the job handler you will be able to see the issue is

    Log::info("Config Value: " . Config::get('Tenant_data_attribute_changed'));            
    Log::info("Tenant value: " . tenant('Tenant_data_attribute_changed'));

Using Nova to manage tenants and change the tenant data. If the above code is in the job handler, following the process documented neither log will have the updated tenant data attributes until either the queue worker is restarted or a different tenant job is processed first.

What would be the implications of the suggested tenant()->end()?

[stancl]

It depends on what you mean by changing the tenant data. In the reproduction steps, you wrote:

Edit Tenant1 data attribute
Which sounds like changing the property without saving it to the DB.

So I wonder how you're actually changing the tenant and for what use case.

[mannis17]

The tenant data is being saved to the database prior to the 2nd queue job beginning to be processed. Consider the scenario where the tenant data contains specific data required by the job. This could be anything from a tenant webhook that needs to be called while/after procesing the job or something as simple as an email that needs to be sent using a specific from to address that is tenant specific. Regardless of the use case tenant data can periodically change, the queue workers need to be able to respect the change in tenant data and not serve stale tenant configuration data, which is what is occuring in the scenario described.

[stancl]

Ah, so it's specifically values being used for config? How are the properties mapped?

[mannis17]

storageToConfigMap in TenancyServiceProvider

[stancl]

Yeah, I mean which ones are being mapped.

[mannis17]

Not sure I understand the question but all the tenant properties are mapped in storageToConfigMap

[stancl]

I'm asking if you can show the exact mapping.

Mapping "all the tenant properties" doesn't make sense.

[mannis17]

For example:

if someValue = 'myvalue'

Job arrives and is processed for Tenant1
Config::get('app.someValue') === 'myvalue'

In nova change someValue for the tenant1 to 'myNewValue'

2nd job arrives for Tenant1 prior to any other Tenant jobs, Config::get('app.someValue') still = 'myvalue'

[mannis17]

Without showing our specific mappings this would be identical:

\Stancl\Tenancy\Features\TenantConfig::$storageToConfigMap = [
'someValue' => 'app.someValue'
],

[stancl]

I don't think I can help with this with these vague examples. I need to see realistic examples of what you're setting there and how you're using them afterwards. Show the actual code from the provider & the job class

[mannis17]

I'll get a sample done up using the saas-boilerplate code to demonstrate the problem