Skip to content
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

Added onError callback if external command fails. #23

Closed
wants to merge 9 commits into from
Closed

Added onError callback if external command fails. #23

wants to merge 9 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Aug 4, 2017

This is needed for example to be able to log external commands that failed (unhandled exceptions in external programs for example).

@coveralls
Copy link

coveralls commented Aug 4, 2017

Coverage Status

Coverage remained the same at 100.0% when pulling 9df17c3 on badyto:master into 114e4dd on peppeocchi:master.

@coveralls
Copy link

coveralls commented Aug 4, 2017

Coverage Status

Coverage remained the same at 100.0% when pulling 9df17c3 on badyto:master into 114e4dd on peppeocchi:master.

@@ -361,7 +375,8 @@ public function run()
if (is_callable($compiled)) {
$this->output = $this->exec($compiled);
} else {
$this->output = exec($compiled);
$outputArray = null;
$this->output = exec($compiled, $outputArray, $this->returnCode);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this force every job to run in foreground?
It seems like a few tests are now failing, the tests that ensure that jobs can run in background.

@peppeocchi
Copy link
Owner

@badyto thank you, it's a reasonable request, can you please check the comment I left?
Did you had a look at the then method to achieve the same result?

It seems like a few tests are now failing, if I remember correctly when passing the other two arguments to the exec function you're basically ignoring the functionality to run jobs in background.

@ghost
Copy link
Author

ghost commented Aug 4, 2017

It is very strange, the tests fail only for PHP7.0 and only here on travis-ci. I have tried to run the tests on my machine both on PHP7.0 and PHP7.1 and they all pass... Furthermore - the one job that failed here on travis-ci says 192 assertions, while the other two tests say 194 assertions. My local machine says 194 assertions for all PHP versions. Is it possible there is something fishy going on with the travis-ci...?

peppeocchi added a commit that referenced this pull request Aug 10, 2017
Similar implementation of the PR #23 submitted by @badyto

Reused the same tests on that PR

There is also a possible breaking change with the output passed to the
callback in the `then` method, when executing a script the output will
be now an array instead of a string.
@peppeocchi
Copy link
Owner

Yes it's a bit weird, I've done a few tests myself and it seems the jobs will keep running in background when passing the other two params to exec.

I've tested a different implementation of your PR, using the then method to handle the script error.
I created that method on v2 because I wanted to leverage functionalities like this, keeping the scheduler as light as possible (because of that, I had to remove a great log integration (#4) written by @carstenwindler)

To give you an example, this is how it should look like

$onError = function () {
    // handle the script error
};

$scheduler->php('script.php')->then(function ($output, $returnCode) use ($onError) {

    if ($returnCode) {
        $onError();
    }

});

I've reused your test to prove that the end result is the same.

Please have a look at this commit 77e2e95, if you want to add any other change please send it to branch v2.x

@ghost ghost closed this Aug 13, 2017
peppeocchi added a commit that referenced this pull request Sep 19, 2017
* Clean up

* Updated phpunit

* Refactoring for v2

* Refectory for v2 pt2

* Required dev php7

Phpunit v6 requires php7 to run

* Fancy helpers

* Prioritise jobs in background

* Use temp arrays to prioritise jobs

* Coveralls

* Coverall config

* Adjusted waiting time on test

* Typo fix

* Removed deprecated flag

* Added Coverage badge to readme

* Removed psr/log suggestion

* Fixed typo in composer.json

* Fixes from styleci

* Downgraded phpunit

Using an older version of phpunit to allow testing on php5, as phpunit
v6 requires php7

* Added php 7.1 supported version

* More fixes from styleci

* Fixes from styleci

* Reordered badges + styleci badge

* Increased tests waiting time when testing file output

* Typo in the documentation

Ref #16

* Fix #20

Added support for SwiftMailer ^6.0

::newInstance() method has been deprecated, along with
Swift_MailTransport.

The default mail transport is now sendmail when using swiftmailer

https://legalhackers.com/advisories/SwiftMailer-Exploit-Remote-Code-Exec
-CVE-2016-10074-Vuln.html

* Implementation of #23 using `then` method

Similar implementation of the PR #23 submitted by @badyto

Reused the same tests on that PR

There is also a possible breaking change with the output passed to the
callback in the `then` method, when executing a script the output will
be now an array instead of a string.

* Added scheduler test

This test ensures that if a job is delayed by e.g. a previous job, it
will run if it was due when the scheduler ran.

* Removed comment from test

*  Allow run() to be executed multiple times  (#24)

* Allow run() to be executed multiple times

The current code expects the run() to be called only once. This is
fine if you start the scheduler from cron each minute and re-initialize
it each time. If you want to manually run the scheduler, or maybe
have a lot of jobs you do not want to init each minute, it would
be useful to call run() multiple times in the lifetime of the
scheduler.

In this case the collected data of the last run should be reset.
the executedJobs, failedJobs and outputSchedule.

* Allow queued jobs to be removed

If the scheduler is used to do multiple runs then it would be useful
to reset all queued Jobs. Currently the only way to do this is by
re-creating the scheduler object. But if the object is injected in the
code then this is not practical..

* Fix StyleCI analysis failure

Comment format fixed.

* Allow run() to be executed multiple times

After discussion with @peppeocchi make the re-running manually
triggered. So added a resetRun() method which can be called before
each run(). Also adjusted the test for this.

* Allow run() to be executed multiple times

The isDue check on the jobs is not provided a datetime in the run()
method. This means they use the creation time of the job as the
'current' time to compare against.

Most likely this creation time is approx the time run() is called so
normally this is no problem. But if setting up the job schedule takes
more time then I would say, using the creation time as run time is
unexpected. And if you run run() multiple times then it will always
run the same jobs because the time never changes.

So now provide an explicit run time for all jobs, which is the same
for all jobs each run.

* Fix StyleCI analysis failure

Remove empty line

* Allow run() to run at arbitrary time (#28)

Currently when run() is called it uses the current time as the run
timestamp. However it would be useful to run the scheduler at a
specific time. So allow an optional param with a DateTime to run().

Reasons for running at a specific time other than now() could be:

- Catching up on 'missed' runs, eg. when the system was down.

- Making sure the scheduler runs at an intended timestamp eg. when
cron is started at midnight it could be slow and start the php process
only at 00:01 and thus missing all midnight schedules.

- Improve testability of the scheduler (fake the time)

* Minor change + documentation new features
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants