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

Adding background:queue commands: status and delete #31630

Merged
merged 1 commit into from
Jun 11, 2018

Conversation

DeepDiver1975
Copy link
Member

@DeepDiver1975 DeepDiver1975 commented Jun 4, 2018

Description

Adding two new commands for listing background jobs and deleting individual jobs

Related Issue

#31617

Motivation and Context

Adding a full feature set around occ and background jobs

How Has This Been Tested?

  • manual testing
  • unit tests

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@@ -0,0 +1,45 @@
<?php

Copy link
Contributor

Choose a reason for hiding this comment

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

missing copyright header

$job = $this->jobList->getById($id);
if ($job === null) {
$output->writeln("Job with id <$id> is not known.");
return;
Copy link
Contributor

Choose a reason for hiding this comment

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

return 1 for the error?

}

$this->jobList->removeById($id);
$output->writeln('Job has been deleted.');
Copy link
Contributor

Choose a reason for hiding this comment

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

return 0

* iterate over all jobs in the queue
*
* @return void
* @since 10.0.3
Copy link
Contributor

Choose a reason for hiding this comment

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

10.0.9?

@DeepDiver1975 DeepDiver1975 force-pushed the feature/queue-status-and-queue-delete branch from d8f890e to d11d73e Compare June 4, 2018 13:26
@codecov
Copy link

codecov bot commented Jun 4, 2018

Codecov Report

Merging #31630 into master will increase coverage by <.01%.
The diff coverage is 66.66%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #31630      +/-   ##
============================================
+ Coverage     62.88%   62.88%   +<.01%     
- Complexity    18381    18393      +12     
============================================
  Files          1151     1153       +2     
  Lines         69111    69151      +40     
  Branches       1260     1260              
============================================
+ Hits          43457    43485      +28     
- Misses        25285    25297      +12     
  Partials        369      369
Flag Coverage Δ Complexity Δ
#javascript 52.39% <ø> (ø) 0 <ø> (ø) ⬇️
#phpunit 64.09% <66.66%> (ø) 18393 <13> (+12) ⬆️
Impacted Files Coverage Δ Complexity Δ
lib/private/BackgroundJob/JobList.php 74% <0%> (-5.86%) 33 <5> (+4)
core/register_command.php 0% <0%> (ø) 0 <0> (ø) ⬇️
core/Command/Background/Queue/Delete.php 100% <100%> (ø) 4 <4> (?)
core/Command/Background/Queue/Status.php 100% <100%> (ø) 4 <4> (?)
lib/private/BackgroundJob/Legacy/RegularJob.php 0% <0%> (ø) 3% <0%> (ø) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a308c24...1a99e5d. Read the comment docs.

@mmattel
Copy link
Contributor

mmattel commented Jun 4, 2018

For the sake of documentation 😄

background:queue:delete 'id'
background:queue:status 'Id', 'Job', 'Last run', 'Arguments'

@mmattel
Copy link
Contributor

mmattel commented Jun 4, 2018

@DeepDiver1975
in command delete, you have id
in command status, you have Id
could you haronize them eg to ID (or whatever but equal) ?

in command status, you have Arguments, I guess this means Job Arguments or ?
if yes, what about renaming to make it clear which arguments are meant, else you could think of occ command arguments

@tomneedham you have in #31617 in code TimedJob.php line 59 id. Please sync with @DeepDiver1975 and have everywhere the same

@DeepDiver1975 , same codline as above in TimedJob.php @tomneedham names a class here as additional text printed. Either this is missing in your PR in status or it maybe equal to your Arguments value. Can you pls sync and harmonize?

Edited, falsly used @butonic instead of @tomneedham , pls excuse

@mmattel
Copy link
Contributor

mmattel commented Jun 4, 2018

@DeepDiver1975
Having a background:queue:delete command.
What happens if I delete all jobs or accidentially one job?
How can I come back to a working state?
What about a background:queue:reset command which resets all jobs to a state like the system got shipped?

@DeepDiver1975
Copy link
Member Author

in command delete, you have id
in command status, you have Id

I see no inconsistency here - id in the argument follows the command argument naming convention and the Id in the status command is a human readable table column - all columns are upper case.

in command status, you have Arguments, I guess this means Job Arguments or ?
if yes, what about renaming to make it clear which arguments are meant, else you could think of occ command arguments

agreed

@DeepDiver1975 , same codline as above in TimedJob.php @tomneedham names a class here as additional text printed. Either this is missing in your PR in status or it maybe equal to your Arguments value. Can you pls sync and harmonize?

job arguments hold the class name as well as required arguments for the execution of the job.
the timedjob is already an instanciated job of one specific type.

the information is identical but it's represenations is different - I see no way to harmonize this right away

What happens if I delete all jobs or accidentially one job?
How can I come back to a working state?

well - this is what backups are for ;-)
seriously: one better knows what he does when killing a job - we can think about a enqueue commend or something

reset is not the way to go because there are multiple sources how jobs are enqueued - we can only restore some of them. I dislike partial solutions

@DeepDiver1975 DeepDiver1975 force-pushed the feature/queue-status-and-queue-delete branch from d11d73e to c8971ee Compare June 4, 2018 21:08
@mmattel
Copy link
Contributor

mmattel commented Jun 5, 2018

@DeepDiver1975 @tomneedham
delete: ->addArgument('id', InputArgument::REQUIRED, 'id of the job to be deleted');
status: $t->setHeaders(['Id', 'Job', 'Last run', 'Job Arguments']);
Execute:->addArgument('jobId', InputArgument::REQUIRED)

All three lines are printed and the user can see it.
The presentation to the user is different id vs Id vs jobId.
Independent for what you decide, the look should be consistent else this is unprofessional.
Same version of how we write it should be taken in all PR´s.

job arguments hold the class name as well as required arguments for the execution of the job

Could we agree to have the same naming in all PR´s for this too, like Job Arguments or what ever

one better knows what he does when killing a job

I would not sign this... I do not know, but a possible solution could be to have a marker in the database for jobs defined by core and you can enable/disable them. All other jobs not beeing part of core do not get/have that marker.

I dislike partial solutions

Agreed - therefore I take the effort to write my thoughts down 😄

@DeepDiver1975
Copy link
Member Author

Execute:->addArgument('jobId', InputArgument::REQUIRED)

I agree to use the same argument name here.

@tomneedham
Copy link
Contributor

Status and delete are useful commands, but only for debugging / analysis, not normal operation. This should be clear in any documentation.

Likewise with my execute command, it is only really for use in exceptional scenarios where we need to forcefully trigger a job on demand for analysis. It should not be expected that these commands are used in normal operation.

@tomneedham
Copy link
Contributor

screen shot 2018-06-05 at 10 34 43

Need to update tests with expected table output

@DeepDiver1975 DeepDiver1975 force-pushed the feature/queue-status-and-queue-delete branch from c8971ee to 1a99e5d Compare June 5, 2018 09:57
@DeepDiver1975
Copy link
Member Author

Need to update tests with expected table output

addressed

@mmattel
Copy link
Contributor

mmattel commented Jun 5, 2018

@DeepDiver1975
being a pain, I know, but id -> Job ID
delete: Line 44, 57
status: Line 54

(all changes including the proposal below need table length adoption ...)

@tomneedham I do not know where the right place to note that is so I do here,
In your PR in Job.php in line 59 and 74 you define a log output having the name class and arguments
@DeepDiver1975 in status beginning with line 54 you define the printable output

Looking at both PR´s I see that \get_class gets called but in job.php it is printed as class while in status it is printed as Job.
I propose to have on both the term Job Name and for arguments the term Job Arguments

@tomneedham
Copy link
Contributor

@mmattel thx, known - waiting for this then I will rebase based on feedback here

@DeepDiver1975 DeepDiver1975 merged commit 5b9c82b into master Jun 11, 2018
@DeepDiver1975 DeepDiver1975 deleted the feature/queue-status-and-queue-delete branch June 11, 2018 19:46
@DeepDiver1975
Copy link
Member Author

we can harmonize print out later on ...

@DeepDiver1975
Copy link
Member Author

@tomneedham feel free to adjust your PR - THX

@PVince81
Copy link
Contributor

@DeepDiver1975 backport to stable10 ?

@DeepDiver1975
Copy link
Member Author

we will backport once #31617 is merged and we backport this together as one

@phil-davis
Copy link
Contributor

Backport stable10 is in PR #34783
Passes CI

@PVince81
Copy link
Contributor

some objections to be clarified in #31617 first

cc @tomneedham

@phil-davis
Copy link
Contributor

phil-davis commented Mar 29, 2019

I added label only-in-master so I can find and recognise this PR easily.
If/when the backporting is merged:

  • remove label only-in-master
  • remove label backport-request

@phil-davis
Copy link
Contributor

some objections to be clarified in #31617 first

cc @tomneedham

Ping @tomneedham or anyone for comment about backporting.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants