-
-
Notifications
You must be signed in to change notification settings - Fork 431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error in Queue ShouldBroadcast since 3.8.5 #1263
Comments
Please post the code of the event. |
This is ONE example - happens with other events, too: |
`<?php namespace App\Events\Tickets; use App\Models\Tenant; class TicketCommentCreated implements ShouldBroadcast
} |
Double check that your queues are configured correctly per the documentation. If they are, create a minimal reproduction example that we can use. See #1260 |
We have a correct configured redis queue which worked perfectly well since 1,5 years... |
A minimal reproduction is written from scratch, so it doesn't matter what business logic you have in your application. |
I'm aware of that - but i want to show it as detailled as possible. And i'll have to look what timeframe i have. I'll look what i can do. |
It should have as little detail (and therefore as few variables and moving parts) as possible, hence minimal reproduction. The least amount of code/simplest setup that reproduces this, so that I can track down where the issue is. |
Similar issue here and downgrading to 3.8.4 resolves the issue. We have a subscriber registered in the EventServiceProvider: class JobEventSubscriber
{
public function handleEvent(JobProcessed|JobFailed $event): void
{
Log::debug(tenant()?->id);
// ^ this is null, in 3.8.4 this is not null
$jobBody = data_get(json_decode($event->job->getRawBody()), 'data.command');
if ($jobBody == null) {
return;
}
$job = unserialize($jobBody);
// ^ this throws error "Database connection [tenant] not configured."
// other stuff
}
public function subscribe(Dispatcher $events): array
{
return [
JobProcessed::class => 'handleEvent',
JobFailed::class => 'handleEvent',
];
}
} |
That's kind of a separate issue since you're hooking into the queue lifecycle directly. The reports were that the old behavior in 3.8.4 made |
I'm 99% sure I'm seeing the same problem. I'll add details from my perspective that should help you in debugging. I've only tested locally with Sail so far, but I'm pretty sure this would happen on a server too. Works with I'm starting with the bare bones (out of the box) saas-boilerplate. Get everything up and running:
Then in routes/tenant.php, I add the following Temp Route:
app/Notifications/UnreadMessageNotification.php:
Create a tenant (u1) via Then in browser I go to: Running 3.8.4, I get:
(and no errors in laravel.log) Running 3.8.5, I get:
And in laravel.log:
|
Thanks for the detailed info @briggsm. Could you please also test without Telescope (should be possible to just disable its watchers(?) in some service provider) |
Hmm, interesting, yes adding:
to .env file, causes the issue not to arise. Hope that piece of information helps you debug. Seems something to do with 3.8.5 and Telescope not working so well together? I assume this is still a 'bug', right? I would still like to be able to use Telescope if possible with 3.8.5. Thank you for looking into this. |
Some issues with the Telescope queue observer logic unserializing model payloads for the tenant connection after the application context reverts to the central app were reported before 3.8.5. I haven't had the time to look for the cause of that (e.g. if something changed in Telescope recently) but it seems the way the queues worked in 3.8.4 made the Telescope logic more reliable, or at least flaky instead of immediately failing. Would be curious to hear if others here are also using Telescope? It seems there are too many moving parts here. The queue change in 3.8.5 was done based on two reports on our Discord that queue:restart signals can be missed by the workers if they remain in the tenant context. Since then, I've had one report of broken queued jobs when injecting model instances that use the tenant connection and the event-related issues mentioned here, though they may have another cause like the Telescope thing. In general I prefer if people just get exceptions like these and are forced to reconfigure some integration or even restructure their jobs to inject model IDs over instances (though again that except for one report I couldn't reproduce seems to be a non issue), rather than the queue worker silently missing critical logic changes during a deployment. That said, if 3.8.5 broke queues in a wider way I think we'd have more reports by now. So for now I'll wait for a repro using pure Tenancy without additional tools like Telescope while tracking the Telescope integration separately (with a workaround likely being just disabling the queue observer, also see the related discussions on our Discord recently). |
Ok, makes sense. Here's a few more details I learned regarding Telescope: If I enabled telescope in .env:
Then in
(Note: the process above doesn't get "DONE" running) and
If I comment out JUST:
and
If I comment out BOTH: No exceptions, just the expected:
|
Geting the same error here after upgrading. Turning of Telescope helps. Bringing back the conditional for $runningTests makes it work again. Just speculating, but maybe Telescope is abusing the testing ENV somehow? |
Just read the above. Support for Telescope observing tenant jobs has been flaky before too (due to how it unserializes the job payloads), it's just more reliably erroring out now. It may be possible to make the integration work, I just don't have the time to look into it now. |
Just to clarify: I never used telescope at all. I set up a minimal demo - but in that it worked. There has to be some sort of setup which wont work... |
Yeah I can see some existing logic being broken without Telescope, but haven't been able to reproduce it myself. Once I have some simple reproduction repo I'll see what's broken and how we can fix that. |
Yeah sorry about that, I've sent a (janky) PR to telescope that fixes my problem laravel/telescope#1539 |
Looks good, since it's addressing an existing Telescope bug there's a better chance it may get merged over just implementing a fix specifically for this package. Perhaps in the future, I could try to come up a more general solution for making tenant models serializable. |
Unfortunately, the merged PR only catches the ModelNotFoundException, so I’ll need to create another PR to address this. I just need to make a minimal reproduction to support the case for catching additional exceptions and errors |
From the stack traces posted above, it seems the thrown exception is The only other approach I can think of that's still limited in |
Yes the exception is pretty strange. Agree that its unlikely that a new exception will get included. Its kind of frustrating as the unserialize method is only used for getting the batch_id which we can get with preg_match instead. The rest of the unserialzied data is discarded. I guess I could just make my own JobWatcher and override getBatchId there, but I'd rather fix it at the "source" |
Hello, i want to confirm that disabling TELESCOPE_CACHE_WATCHER seems to fix the issue |
Setting TELESCOPE_JOB_WATCHER=false in my .env file solved this for me. |
Bug description
I always get an error "Database connection [tenant] not configured." on an event that implements Shouldbroadcast.
This error was introduced since upgrading to 3.8.5 - downgrading to 3.8.4 resolves the issue.
Steps to reproduce
Create a event that implements ShouldBroadcast with broadcastOn and broadcastWith method.
Expected behavior
No error
Laravel version
10.48.22
stancl/tenancy version
3.8.5
The text was updated successfully, but these errors were encountered: