ethan3600 / magento2-cronjobmanager Goto Github PK

Timeline won't load on our production servers, it generates:

Warning: DOMDocumentFragment::appendXML(): Entity: line 1: parser error : CData section too big found in /vendor/magento/framework/View/TemplateEngine/Xhtml/Template.php on line 60

All current versions of this extension have this restraint; "php": "~7.0.0|~7.1.0",.

Do you have any idea when this extension will be PHP 7.2 compatible or maybe it is, but it hasn't been tested yet?

Need to backport PRs:

• #25

• #26

• #27

• #30

• #31

• Dispatch

• Delete

• Schedule Now

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Cron Job Manager Version [e.g. 1.6.4]
• Magento Version [e.g. 2.3.0]
• PHP Version [e.g. 7.0.33]

Additional context
Add any other context about the problem here.

Objective:

Rebrand existing "timeline" as visualizer and create a new Timeline based on something like Google charts api

The goal is to have a higher level perspective, over the visualizer, to gather a more granular view of cron jobs and where they are running.

Is your feature request related to a problem? Please describe.
I want to kill specific running jobs via CLI, e.g. the indexer as part of the deployment process

Describe the solution you'd like
bin/console cronmanager:killjob <jobcode> would kill any running job of <jobcode>

Possible configuration

A flag could be added to choose between killing directly or sending a kill request that would be executed by the next cron run (the latter should be default behavior)

Is your feature request related to a problem? Please describe.
Currently, cronjobs can be disabled by configuring an empty schedule. This is not obvious.

Describe the solution you'd like
Add a column to the grid with red and green "Enabled"/"Disabled". In the form, use a checkbox.

• Create unit tests

• Ensure code is PSR-2 compliant

• Audit performance

• Mitigate bottlenecks if any exist

The timeline seems to slow down after hitting around 2k records in cron_schedule.

Wild guess: This is likely due to all the subscribers KO has for each binding

The goal of this Issue is to resolve problems with speed, and the amount of records we can handle in the timeline.

There should be a "max" number of records we support because there's an argument that you shouldn't have over a certain amount of records stored in cron_schedule. We'll definitely want to get a specific number for this

This is a follow up issue that was derived from issue #50

Describe the bug
Travis builds fail with messages like:

  Could not parse version constraint 1.x-develop-dev#62afe79742835defe6fe42a3  
  0a90689f1f31dc0e: Invalid version string "1.x-develop-dev#62afe79742835defe  
  6fe42a30a90689f1f31dc0e"                                                     

Is your feature request related to a problem? Please describe.
PHP 7.0 has reached end of life December 2018 and we should not need to support it any longer

Describe the solution you'd like
Remove PHP 7.0 from the build matrix and allow language features from PHP 7.1 like nullable types and constant visibility.

This can be done with a 1.8.0 or 2.0.0 release, depends how conservative our definition of backwards compatibility should be.

First, I could not longer login to my backend. Error was: Class Magento\\Framework\\Stdlib\\Cookie\\PublicCookieMetadataFactory does not exist

I fixed that with flushing var/generation and a magento setup:di:compile

After that i could login to the backend but now all tasks, scheduled for execution after installation-time are still open (seen in the database). If i want to see the list in my backoffice, it loads infinity. Also the timetable is not loading and flush jobs did nothing (no changes if i check db).

i did this by flush it with phpmyadmin now. this has no effect to the problems, even without any rows in my db the tables in backoffice still loading infinity.

now i removed the tool with composer. by remving it it installas tons of new tools (zendframework, phpunit, and some other stuff). my magento still works but this toll is still blocking my cron jobs now!

UPDATE: After flusching all jobs in db a new punch of jobs where created automatically (not as configured every 30min, now its every 5 min.) it works again. but the timetable and -frame still loading infinty

Describe the bug
The job filter in the schedule grid is has the type "text". The existing source model can be used to have a dropdown filter

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Cron Job Manager'
2. Click on 'Filters'

Expected behavior
Filter by job code shows a dropdown of all jobs

Additional context
This may be debatable. Selecting jobs from a dropdown is convenient, but it removes the possibilty to search for multiple jobs by prefix

Figure out if in-line editing is useful and easier to use

Implementation code already in place, but commented out

Is your feature request related to a problem? Please describe.
If cron jobs are distributed on several servers, e.g. by cron group, the check for dead processes can return false positives, resulting in "Process went away" messages.

Describe the solution you'd like
Save the hostname together with the pid and filter by pid and hostname. The feature should be optional, because it may cause different issues if the hostname changes during deployments.

Describe the bug
When a cron is run using bin/magento cronmanager:runjob <cronjob>, the cron starts as the first store view of the default website.
This is inconsistant with the default cron bin/magento cron:run which starts with the admin store view.

To Reproduce
Steps to reproduce the behavior:

1. Run any bin/magento cronmanager:runjob <cronjob> using xdebug
2. When execution reaches Magento\Store\Model\StoreResolver::readStoresData():
   • $this->runMode == "website" and $this->scopeCode == null
   • Consequence: Magento\Store\Model\StoreManager::$currentStoreId is set to 1.
   • (module entry point is EthanYehuda\CronjobManager\Console\Command\Runjob::execute() on first line)
3. Run bin/magento cron:run using xdebug
4. When execution reaches Magento\Store\Model\StoreResolver::readStoresData():
   • $this->runMode == "store" and $this->scopeCode == "admin"
   • Consequence: Magento\Store\Model\StoreManager::$currentStoreId is set to 0.

Expected behavior
Using cronmanager:runjob should be consistant with native magento cron.
This could (and does, in my case) cause issues when processing store-related things, like loading or saving products.

Environment (please complete the following information):

• OS: Host macOS, magento running in Vagrant Ubuntu
• Browser: Terminal
• Cron Job Manager Version: v1.7.1 (commit 468c219)
• Magento Version: 2.3.0
• PHP Version: 7.2.13

Additional context
I'll continue to investigate this issue and hopefully propose a pull request when I'll found a solution if you're not faster than me.

Job Configurations should include the following features:

• Allows user to change the frequency of cron jobs (i.e. */5 * * * * to */15 * * * *)

  • Must include proper validations for cron expressions

• Allow users to enable/disable cron jobs

• Link to system configurations for cron jobs

On magento 2.2.3 when clicking on Job Configuration or Select > edit I get the below error:

1 exception(s):
Exception #0 (Exception): Notice: Undefined index: name in [store_path]/vendor/ethanyehuda/magento2-cronjobmanager/Model/Schedule/Source/Schedule.php on line 32

Describe the bug
Travis builds for Magento 2.3 fail with

Exception: Could not connect to the Amqp Server.
In InstallCommand.php line 264:
  [InvalidArgumentException]
  Parameter validation failed

because the default install-config-mysql.php.dist file contains AMQP configuration

Description

When saving a new Cron it saves the scheduled time in UTC time.

When viewing the dashboard you can see the cron is scheduled 4 hours ahead (store is in New York time zone).

But if go to the edit page for the cron job you made, open the calendar widget, and re-enter the same time it accurately displays in the dashboard, and runs at the requested scheduled time.

Steps to Reproduce

1. Go to Cron Job Dashboard

2. Click "Add New Cron Job"

3. Save a new Cron Job and return to the Cron Job Dashboard (keep tack of the scheduled time)

Expected result:

• Cron job Dashboard displays the new Cron Job with the "scheduled at" time that was entered in the save form

Actual result:

• Cron Job gets scheduled in UTC time instead of the store time

Is your feature request related to a problem? Please describe.
The timeline view is a nice overview but I'd like to see more details. Also depending on the number of scheduled jobs, the timeline view has performance issues.

Describe the solution you'd like
A paginated grid view of the schedule as alternative to the timeline

Parse error: syntax error, unexpected '?' in /data/web/current/vendor/ethanyehuda/magento2-cronjobmanager/Model/ScheduleManagement.php on line 100

Hi Ethen
The module looks great!!

I get this issue:
After installation, the static files are not being built correctly.
Its building:
pub/static/adminhtml/Magento/backend/en_US/EthanYehuda_CronjobManager/template..
and looking for:
pub/static/adminhtml/Magento/backend/en_US/cronjobManager/template..

I get 404 on the html requests

Is your feature request related to a problem? Please describe.
It takes several clicks to navigate between the different screens, the navigation is not intuitive

Describe the solution you'd like

• Always show "Dashboard", "Timeline" and "Configuration" links
• Rearrange "Flush Jobs", "Run Cron" and "Add Cron" buttons

Describe alternatives you've considered
Add multiple items in the "System" main menu (downside: gets bloated quickly)

• Track PID of each cron job

Resolved in PR #57

• Ability to kill processes while they're running

Create Cron Jobs that are disabled by default that are useful for everyday use i.e.

• Full Reindex

• Cache flush storage

etc..

The goal is to expose common functionality that is not natively accessible.

A user should be able to schedule these processes based on a custom frequency, create a schedule for a one-time-run, or run "Schedule Now" so they can just run it immediately in the background.

Magento cloud doesn't support creating your own crons so this should be useful for people who want to do a full reindex, for example, at a particular time of day/night

They should be disabled by default so users can define how they want them to be used on the system

The \EthanYehuda\CronjobManager\Helper\Processor::runJob() method has 99% the same code of Processor::runScheduledJob().

The only difference between these two methods is when the schedule object is saved:
runJob() directly call the save() method of the schedule object itself (which is deprecated according to Magento 2 best practices) whereas runScheduledJob() runs the save() method from the object getResource().

I think runJob() should be deleted if possible, or at least being updated as deprecated and pointing to runScheduledJob() method.

Hi I'm running your extention over Magento 2.2.3 and the jobs schedules are being duplicated, check the scheduled date below.

In this particular case (sales_send_order_emails) I've modified the execution frecuency to every five minutes (*/5 * * * *)

This issue is causing emails being send twice. What could I do to avoid this?

Is your feature request related to a problem? Please describe.
I want to see quickly which jobs have an error or working status

Describe the solution you'd like
Colorize the status column:

• Pending: gray
• Running: yellow
• Success: green
• Missed: ? (something less drastic than red, maybe orange or black)
• Error: red
• Killed: red

Additional context
Example of colorized columns from the cache management:

Describe the bug
Swagger breaks with this exception:

<response>
<message>
Notice: Undefined offset: 1 in /var/www/html/vendor/magento/framework/Reflection/TypeProcessor.php on line 896
</message>
<trace>
#0 /var/www/html/vendor/magento/framework/Reflection/TypeProcessor.php(896): Magento\Framework\App\ErrorHandler->handler(8, 'Undefined offse...', '/var/www/html/v...', 896, Array) #1 /var/www/html/vendor/magento/framework/Reflection/TypeProcessor.php(677): Magento\Framework\Reflection\TypeProcessor->getParamDocBlockTag(Object(Zend\Code\Reflection\ParameterReflection)) #2 /var/www/html/vendor/magento/module-webapi/Model/Config/ClassReflector.php(93): Magento\Framework\Reflection\TypeProcessor->getParamDescription(Object(Zend\Code\Reflection\ParameterReflection)) #3 /var/www/html/vendor/magento/module-webapi/Model/Config/ClassReflector.php(72): Magento\Webapi\Model\Config\ClassReflector->extractMethodData(Object(Zend\Code\Reflection\MethodReflection)) #4 /var/www/html/vendor/magento/module-webapi/Model/ServiceMetadata.php(127): Magento\Webapi\Model\Config\ClassReflector->reflectClassMethods('EthanYehuda\\Cro...', Array) #5 /var/www/html/vendor/magento/module-webapi/Model/ServiceMetadata.php(156): Magento\Webapi\Model\ServiceMetadata->initServicesMetadata() #6 /var/www/html/vendor/magento/framework/Interception/Interceptor.php(58): Magento\Webapi\Model\ServiceMetadata->getServicesConfig() #7 /var/www/html/vendor/magento/framework/Interception/Interceptor.php(138): Magento\Webapi\Model\ServiceMetadata\Interceptor->___callParent('getServicesConf...', Array) #8 /var/www/html/vendor/magento/framework/Interception/Interceptor.php(153): Magento\Webapi\Model\ServiceMetadata\Interceptor->Magento\Framework\Interception\{closure}() #9 /var/www/html/generated/code/Magento/Webapi/Model/ServiceMetadata/Interceptor.php(26): Magento\Webapi\Model\ServiceMetadata\Interceptor->___callPlugins('getServicesConf...', Array, Array) #10 /var/www/html/vendor/magento/module-webapi/Model/Rest/Swagger/Generator.php(923): Magento\Webapi\Model\ServiceMetadata\Interceptor->getServicesConfig() #11 /var/www/html/vendor/magento/module-webapi/Controller/Rest/SchemaRequestProcessor.php(53): Magento\Webapi\Model\Rest\Swagger\Generator->getListOfServices() #12 /var/www/html/vendor/magento/module-webapi/Controller/Rest.php(188): Magento\Webapi\Controller\Rest\SchemaRequestProcessor->process(Object(Magento\Framework\Webapi\Rest\Request\Proxy)) #13 /var/www/html/vendor/magento/framework/Interception/Interceptor.php(58): Magento\Webapi\Controller\Rest->dispatch(Object(Magento\Framework\App\Request\Http)) #14 /var/www/html/vendor/magento/framework/Interception/Interceptor.php(138): Magento\Webapi\Controller\Rest\Interceptor->___callParent('dispatch', Array) #15 /var/www/html/vendor/magento/framework/Interception/Interceptor.php(153): Magento\Webapi\Controller\Rest\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http)) #16 /var/www/html/generated/code/Magento/Webapi/Controller/Rest/Interceptor.php(26): Magento\Webapi\Controller\Rest\Interceptor->___callPlugins('dispatch', Array, Array) #17 /var/www/html/vendor/magento/framework/App/Http.php(136): Magento\Webapi\Controller\Rest\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http)) #18 /var/www/html/generated/code/Magento/Framework/App/Http/Interceptor.php(24): Magento\Framework\App\Http->launch() #19 /var/www/html/vendor/magento/framework/App/Bootstrap.php(258): Magento\Framework\App\Http\Interceptor->launch() #20 /var/www/html/pub/index.php(40): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http\Interceptor)) #21 {main}
</trace>
</response>

To Reproduce
Steps to reproduce the behavior:

1. Go to: https://your.domain/swagger
2. You won't be able to use swagger at all

See the exception

1. Go to https://your.domain/rest/all/schema?services=all
2. You should not see a stacktrace

Expected behavior
You should be able to use swagger to see all endpoints

Environment:

• Cron Job Manager Version 1.8.0
• Magento Version 2.3.1
• PHP Version 7.2
• Developer mode ON

Additional context
version 1.7.1 work in the same environment

• Displays useful information on cron jobs

  • longest lasting cron

  • most resource intensive

  • most frequently run cron

  • etc

Could not find package ethanyehuda/magento2-cronjobmanager at any version matching your PHP version 7.1.11.0
Newest extension version (1.1.0) php: ~5.6.5|7.0.2|7.0.4|~7.0.6
Can you support PHP version 7.1?

Cheers,
Juhani

While dispatching a failed cron, I received this error message.
Cron Manager 1.3.3
Magento 2.2.3, Developer mode

1 exception(s):
Exception #0 (Exception): Warning: sprintf(): Too few arguments in [store_path]/vendor/ethanyehuda/magento2-cronjobmanager/Helper/Processor.php on line 111

Exception #0 (Exception): Warning: sprintf(): Too few arguments in [store_path]/vendor/ethanyehuda/magento2-cronjobmanager/Helper/Processor.php on line 111
#0 [internal function]: Magento\Framework\App\ErrorHandler->handler(2, 'sprintf(): Too ...', '/home/awningwor...', 111, Array)
#1 [store_path]/vendor/ethanyehuda/magento2-cronjobmanager/Helper/Processor.php(111): sprintf('Cron Job %s has...', 'elasticsuite_in...', 'Requested store...')
#2 [store_path]/vendor/ethanyehuda/magento2-cronjobmanager/Model/Manager.php(121): EthanYehuda\CronjobManager\Helper\Processor->runJob(1524054352, 1524054352, Array, Object(Magento\Cron\Model\Schedule), 'default')
#3 [store_path]/vendor/ethanyehuda/magento2-cronjobmanager/Controller/Adminhtml/Manage/Job/Dispatch.php(52): EthanYehuda\CronjobManager\Model\Manager->dispatchCron('93203', 'elasticsuite_in...')
#4 [store_path]/generated/code/EthanYehuda/CronjobManager/Controller/Adminhtml/Manage/Job/Dispatch/Interceptor.php(24): EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch->execute()
#5 [store_path]/vendor/magento/framework/App/Action/Action.php(107): EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch\Interceptor->execute()
#6 [store_path]/vendor/magento/module-backend/App/AbstractAction.php(229): Magento\Framework\App\Action\Action->dispatch(Object(Magento\Framework\App\Request\Http))
#7 [store_path]/vendor/magento/framework/Interception/Interceptor.php(58): Magento\Backend\App\AbstractAction->dispatch(Object(Magento\Framework\App\Request\Http))
#8 [store_path]/vendor/magento/framework/Interception/Interceptor.php(138): EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch\Interceptor->___callParent('dispatch', Array)
#9 [store_path]/vendor/magento/module-backend/App/Action/Plugin/Authentication.php(143): EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#10 [store_path]/vendor/magento/framework/Interception/Interceptor.php(135): Magento\Backend\App\Action\Plugin\Authentication->aroundDispatch(Object(EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch\Interceptor), Object(Closure), Object(Magento\Framework\App\Request\Http))
#11 [store_path]/vendor/magento/framework/Interception/Interceptor.php(153): EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#12 [store_path]/generated/code/EthanYehuda/CronjobManager/Controller/Adminhtml/Manage/Job/Dispatch/Interceptor.php(39): EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch\Interceptor->___callPlugins('dispatch', Array, NULL)
#13 [store_path]/vendor/magento/framework/App/FrontController.php(55): EthanYehuda\CronjobManager\Controller\Adminhtml\Manage\Job\Dispatch\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#14 [store_path]/vendor/magento/framework/Interception/Interceptor.php(58): Magento\Framework\App\FrontController->dispatch(Object(Magento\Framework\App\Request\Http))
#15 [store_path]/vendor/magento/framework/Interception/Interceptor.php(138): Magento\Framework\App\FrontController\Interceptor->___callParent('dispatch', Array)
#16 [store_path]/vendor/magento/framework/Interception/Interceptor.php(153): Magento\Framework\App\FrontController\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#17 [store_path]/generated/code/Magento/Framework/App/FrontController/Interceptor.php(26): Magento\Framework\App\FrontController\Interceptor->___callPlugins('dispatch', Array, Array)
#18 [store_path]/vendor/magento/framework/App/Http.php(135): Magento\Framework\App\FrontController\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#19 [store_path]/vendor/magento/framework/App/Bootstrap.php(256): Magento\Framework\App\Http->launch()
#20 [store_path]/pub/index.php(37): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http))
#21 {main}

Maintaining a reasonable history view of 3 days of both success and error[how else can you check to see if something has spiked/started to cause problems] will fill up the cron schedule table and make it unusable.

Having an ARCHIVE of cron jobs instead, a duplicate table to record all cron jobs removed from the main table, would provide this history without breaking cron.

The initial implementation does not even need to provide a UI beyond setting time limits for how long to maintain archived data. Just keeping a table of the history allows command line lookup and future releases could look into providing a ui.

I'd like the Cron Job Manager to expose a REST Api so third parties can manipulate and keep track of the Crons in Magento.

Maybe even a GraphQl API?

Needs a face lift

Hi,

its likely to happen, but when there are no jobs timeline is messed up:

http://prntscr.com/kg4s67

Ivan

Hi @Ethan3600

I'm seeing the following error using Version 0.2.1 with Magento 2.1.5

Unable to resolve the source file for 'adminhtml/Magento/backend/de_DE/cronjobManager/template/timeline/toolbar.html' #0 /html/******/vendor/magento/framework/App/StaticResource.php(97): Magento\Framework\View\Asset\File->getSourceFile() #1 /html/******/vendor/magento/framework/App/Bootstrap.php(258): Magento\Framework\App\StaticResource->launch() #2 /html/******/pub/static.php(13): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\StaticResource)) #3 {main}

Would be great, if you could help me regarding this issue.

Cheers

For now, when we use bin/magento cronjobmanager:runjob, the scheduled task is saved to Magento database before being actually running.
This might cause a race condition in a production environment, if the native cron manager is triggered between schedule creation and schedule actual start from the CLI command.

I'd suggest 3 changes:

• ScheduleManagement::createSchedule() should no longer save the created schedule to database: it should be caller's responsibility.
• Update ScheduleManagement::execute() to take a Schedule object instead of a scheduled ID. This would allow the previous created object to be executed, without being saved. This suggestion make require some adaptation, as this method is a part of the WebAPI.
• ScheduleManagement::execute() should set the Schedule Object State to Schedule::STATUS_RUNNING along setting the Executed At.

Is your feature request related to a problem? Please describe.
I want to see if a "running" cronjob is actually still running or has crashed

Describe the solution you'd like

• Show process id in grid
• Regularly check if processes are still running, show "last seen" timestamp in grid
• Add "kill" action

When running in Production mode. a 404 response is shown in the network console that _module.css could not be included. This is because the less is not compiled on the fly into the css file. Instead, production mode imports all _module.less files from modules into the main styles.css file. In developer mode, this file is also included by default. The css include in layout is unnecessary in developer mode and creates a 404 in Production mode.

Just installed this extension for testing. So far, so good. :D However...

Appears the Timeline feature doesn't work in the latest versions of Safari on MacOS Mojave. Works great in Chrome though. In Safari, none of the bars show up...just the rows showing the name of the tasks followed by a grey bar. So...something is askew! :P

Using version 0.4.0 on Magento 2.1.10 in production mode i get this error:

[Tue May 01 15:11:14.275469 2018] [proxy_fcgi:error] [pid 3946] [client 87.213.39.106:16732] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: Argument 1 passed to EthanYehuda\\CronjobManager\\Controller\\Adminhtml\\Config\\Job\\MassScheduleNow::__construct() must be an instance of Magento\\Framework\\View\\Result\\PageFactory, instance of Magento\\Framework\\ObjectManager\\ObjectManager given, called in /var/www/vhosts/score/httpdocs/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php on line 93 and defined in /var/www/vhosts/score/httpdocs/vendor/ethanyehuda/magento2-cronjobmanager/Controller/Adminhtml/Config/job/MassScheduleNow.php:19\nStack trace:\n #0 /var/www/vhosts/score/httpdocs/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(93): EthanYehuda\\CronjobManager\\Controller\\Adminhtml\\Config\\Job\\MassScheduleNow->__construct(Object(Magento\\Framework\\ObjectManager\\ObjectManager))\n #1 /var/www/vhosts/score/httpdocs/vendor/magento/framework/ObjectManager/Factory/Compiled.php(88): Magento\\Framework\\ObjectManager\\Factory\\AbstractFactory->createObject('EthanYehuda\\\\Cro...', Array)\n #2 ...\n', referer: https://support-score.itnova.nl/sitemanager_53RfIfauG6CnZGS/cronjobmanager/config/index/key/dd48cb763ad077fb2bf32652df3d040976b30970adfea962d9290b31a0943746/

when i use the "Schedule now" option on from the Job configuration.

i've done some debugging and found out that renaming
magento2-cronjobmanager/Controller/Adminhtml/Config/job
to
magento2-cronjobmanager/Controller/Adminhtml/Config/Job

solves the issue.

• lots of misnamed variables

• Probably don't need to extend the Magento OOB timeline component any more

• Find a way to simplify and improve

• Re-brand as visualizer

Prerequisite to issue #29

I've some tasks that take 30-40 minutes to complete. After ~3 minutes those tasks are marked as error. Later, after the task finishes successfully, it's marked correctly has "Success".

Add a configuration to enter 1 or more email addresses to alert when a cron job fails

hi;
i had created new cron on localhost under add new cron , and i have scheduled under job configuration for every 1 min ,
in that module there is a code to print in the logger in every 1 min,but the scheduler to dont run.
and if i use dispatch now then it runs only once.
let me know how to run for every min on localhost.

Thanks.