Queued landlord jobs fail while tenant jobs succeed

[krand-dsa]

I'm using laravel-multitenancy with Filament. Filament provides a password reset feature on the login page, which sends a link to the user via email. This email gets queued and sent by the queue worker.
In my case this feature works perfectly fine with tenants. Emails are sent out without any problems.
However with the landlord the following exception is thrown when the queue worker tries to send the mail and the job gets deleted from the queue:

CurrentTenantCouldNotBeDeterminedInTenantAwareJob(code: 0): The current tenant could not be determined in a job named Filament\\Notifications\\Auth\\ResetPassword. No tenantId was set in the payload. at /var/www/html/vendor/spatie/laravel-multitenancy/src/Exceptions/CurrentTenantCouldNotBeDeterminedInTenantAwareJob.php:12)

The stacktrace shows that the MakeQueueTenantAwareAction calls bindOrForgetCurrentTenant(); on line 33, which in turn on line 137 tries to find a tenant, which fails at line 119 because the currentTenantContextKey (tenantId) is not found. Then the job gets deleted and the Exception thrown.

When comparing the queued jobs for tenants and landlord, I recognised that tenant jobs contain the following part at the end, which is missing at landlord jobs:

"illuminate:log:context":{"data":{"tenantId":"i:1;"},"hidden":[]}

This missing part (especially the "tenantId" seems to be the reason, why the exception is thrown.

When reading the code of the MakeQueueTenantAwareAction, I can't identify how the landlord case would be handled for tenant aware jobs, as they in any case would enter findTenant where they finally fail.

Therefore my question is: Is this a bug in the MakeQueueTenantAwareAction and if not how is the landlord case meant to be handled?