I have an "/x" api endpoint that dispatches a "MakeXJob" Job (without ShouldQueue). In local environment without Octane, it works just fine. But in Server with Octane (Swoole), does not dispatching the job. I am dispatching in command line with tinker (to see if there is a problem), and it works expected again.
Has anyone encountered such a problem before? This is the second Octane(!) related issue I faced. Of course I am not sure if they are "Octane" related, it's just an idea.
Here is other issue: Laravel Request Class prepareForValidation not reflected in $request->get()
Related
I seriously cannot wrap my head around this.
Locally the tag field of Laravel Nova 4.0 works like a charm (https://nova.laravel.com/docs/4.0/resources/fields.html#tag-field). On production it results in a 404 page on the resource-detail page.
Everything seems to be the same. Same laravel nova version (4.20.2), same data, same other packages.
I've narrowed it down to this call being sent on production:
Request URL: https://api.foodinfluencersunited.nl/nova-api/tags/23a1f0b3-eaac-45c3-b6da-7c1acda08f9d/preview
Which is not sent locally. This call should either not be sent on production (since the tagField has "withPreview" off, or at least it should be sent to:
Request URL: https://api.foodinfluencersunited.nl/nova-api/roles/23a1f0b3-eaac-45c3-b6da-7c1acda08f9d/preview
Since the uuid which is sent is the UUID of a Role-resource.
Does anyone have any idea where I should search for the solution?
I'm trying to at least get the error locally as well.
Imported the production data to local server and made sure that everything else is similar.
It appeared I had out-of-date js on one of my production servers. php artisan nova:publish did not run automatically on one of them. That solved my issue.
I have the following code in Kernel.php. The purpose is to run the command between 23:000 and 04:00
$schedule->command('moving:vehicles -vvv')
->between('23:00', '04:00')
->everyTenMinutes();
However, the cron starts executing the command at 17H00. I have tried to replicate the same by send emails into mailtrap and I get different results.
https://github.com/laravel/framework/issues/28943
The link above explains why the schedule was not running as intended. It was a bug in Laravel 5.x and it was resolved in version 6. I changed direction to use https://crontab.guru/#*/10_0-4,23_*_* to solve the issue I faced.
I'm using Rollbar in a Laravel 5.7 app, and the following situation has been confusing and frustrating me.
It seems that my \app\Exceptions\Handler.php file isn't getting used normally.
I finally noticed that https://docs.rollbar.com/docs/laravel#section-exception-logging says:
"For Laravel 5.6, all errors which are normally handled by \App\Exceptions\Handler are going to be reported to Rollbar by default."
How can I disable this default functionality?
My \app\Exceptions\Handler.php will use Log to send data to Rollbar too, but it's important for me to run my whole exception handler since there is other functionality in there that needs to happen first.
Thanks.
I'm trying to set up a CRON job for my laravel 4.2 app and am strugglng to get things to work.
I've created a command which works successfully from the command line. I first tried created a CRON task with my service provider but was unable to get this to work. I tried:
/usr/bin/php /var/www/vhosts/mydomin.co.uk/subdomains/golfmanager/httpdocs/artisan reminder:week
This does not appear to work
I then tried:
/usr/bin/lynx -dump /var/www/vhosts/mydomain.co.uk/subdomains/golfmanager/httpdocs/artisan reminder:week
That failed to work either. My understanding is Lynx is a browser? but I assume because all the traffic is re-routed this approach won't work for a Laravel app?
So I then installed the package [liebig/cron][1] with a view to getting that up and running. I created a cron task with an external provider 'cronservice' which appears to be triggering but I'm not getting the expected results from the task.
I have configured the package as described and have current placed the following in bootstratp/start.php
Event::listen('cron.collectJobs', function() {
Cron::add('reminder-week', '*/15 * * * *', function() {
echo "Running Task";
Artisan::call('reminder:week');
return true;
});
});
The package logs activity to a database. I can see a log entry suggesting it's fired but can't see an entry that the job has worked. Laravel log files suggest there is an httpfoundexception
I've not created a route for CRON - the readme suggests it's using an internal one?
I'm quite confused. I'd like to stick with the package approach and the external provider but not sure if I now need to create a route and how I can test the set up is correct and the jobs will work.
I've tried running the script from the browser `http://mydomain.com/cron.php?key=xxxxx' but that also throws an httpnotfound exception
ANy help appreciated to get this to work
I changed the Event::listen code to app/start/glopal.php and all working now.
Re-read the readme more carefully!
I'm running Laravel 4.1.25 with iron-io/iron_mq 1.5.1 and this is my first try at queues. According to the documentation (http://laravel.com/docs/queues), when you're done processing a job, you should delete it from the queue.
However, during my testing, I've noticed that Laravel will return any job to the Iron.io queue if it throws an exception (documented behaviour), but if a job succeeds with no exceptions thrown, it vanishes from the queue.
Is that something specific to Iron.io (using a pull queue), and will it hurt if I run $job->delete() at the end, despite the fact that Laravel is clearing processed jobs already?
So after digging around in the source code a bit, I found that if you add public $delete = true; to the class that contains your fire() method, Laravel will automatically delete completed jobs. This is referenced from Illuminate\Queue\Worker process(), where it checks for $job->autoDelete(), after calling $job->fire().
In my case this wasn't set, and I was unable to reliably reproduce the issue I was trying to fix. I'm settling for just setting $delete, since Laravel will return an Exception-throwing job to the queue regardless.