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.
Related
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()
The DialogFlow CX with Page Form Parameters was working well in the test simulator and recently, my chat bots are not responding after user inputs.
When i tried to troubleshoot the issue i realized that the $page.params.status='FINAL' or the $page.params.someparameter.status='UPDATED' events are not firing properly. Due to this the routes are getting failed.
Initially i thought the issue is in my Project. Then i tried the prebuilt agent (travel-baggage claim) in another project. Even that behaves the same without any response after the user inputs are collected.
I also reported this issue to the Developer Advocates in Twitter and updating here as well to get some response from the community.
I’ve tried to replicate your use case but I was able to successfully trigger the condition routes $page.params.status = "FINAL" and $page.params.parameter-name.status = "UPDATED" as expected and transition to the defined page from my end.
See the following for reference:
$page.params.status = "FINAL"
$page.params.parameter-name.status = "UPDATED"
To troubleshoot the issue, you may check if all the conditions defined in your condition route are fulfilled. Also, you may need to check if the condition rules applied is OR or AND. If AND, make sure that all conditions are fulfilled in order to transition to the defined page or flow.
As for the prebuilt agent Travel: baggage claim, I was also able to replicate the same behavior. However, I noticed that this is a different issue since the issue is caused by the webhook being unable to provide a response and not caused by triggering the condition route. I was able to verify this by adding a static response on the condition route and by checking the logs from the simulator. See screenshots below for more information.
Static response
Log snippet from simulator
I tried creating a new flow and migrated all the pages and it works well. I suspect the flow got corrupted when i programmatically tried to update via API.
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!
There are plenty of examples of similar problems littered around the web but none of their solutions seem to fix this particular variation. Any suggestions would be appreciated.
Usually this problem occurs because a rogue link is causing a request for a resources like a favicon or css file to hit the dispatcher more than once, thus causing multiple dispatch processes and therefore multiple rows in your database.
I have checked that all the links on this very simple example page do actually resolve to the resource to which they point.
The session handler is setup as follows:
Zend_Db_Table_Abstract::setDefaultAdapter($db);
Zend_Session::setSaveHandler(new
Zend_Session_SaveHandler_DbTable($config->session->toArray()));
The db logging is setup as follows:
$writer = new Zend_Log_Writer_Db($db, $config->log->tableName,
$config->log->columnMap->toArray());
$logger = new Zend_Log($writer);
Both objects are correctly setup and can read and write to and from the database. Only everything happens twice. If I put a test log message anywhere in the application it is written into the database twice. If I increment three variables with every call to the index action - one stored in the session, one passed around via a Zend_Registry object and another local to the indexAction - only the session variable is incremented by 2. The Apache access log shows the correct amount of requests being fired from the page load and all have good response codes of either 200 or 304 (unchanged).
I have tried disabling all head links.
I have tried disabling the layout entirely.
I have localised everything to the dispatcher and exited before dispatch is run.
In all cases the extra write/increment takes place.
Any thoughts?
Thanks in advance for any help.
I seem to have found and fixed the issue. Chrome (and possibly all Webkit browsers) issues an additional HEAD request on top of the GET which means the application is hit twice and anything session based will be triggered as a result of both requests. My temporary solution is to put the following code near the start of my index.php file.
if ("HEAD" == $_SERVER['REQUEST_METHOD']) {
exit;
}
I hope that helps anyone with the same issue.
Google Chrome always asks for the favicon.ico by making annoying requests to the server. Take care about this in Chrome.
For more information:
http://framework.zend.com/issues/browse/ZF-11502?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
Thanks to the Sebastian Galenski contribution.