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

Scheduler API #89

Closed
wants to merge 7 commits into from
Closed

Scheduler API #89

wants to merge 7 commits into from

Conversation

graywolf336
Copy link
Contributor

@graywolf336 graywolf336 commented Nov 5, 2018

To Do list:

  • Review codebase and merge conflicts
  • Find a new cron parser (as the package later is no longer active)
  • Add tests covering the Scheduler components
  • Implement bridges on Rocket.Chat side

@graywolf336 graywolf336 added the ⏳ in progress Items which are currently a work in progress label Nov 5, 2018
@codecov
Copy link

codecov bot commented Nov 5, 2018

Codecov Report

❗ No coverage uploaded for pull request base (master@18d30f9). Click here to learn what that means.
The diff coverage is 57.14%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master      #89   +/-   ##
=========================================
  Coverage          ?   54.94%           
=========================================
  Files             ?       70           
  Lines             ?     2448           
  Branches          ?      362           
=========================================
  Hits              ?     1345           
  Misses            ?     1103           
  Partials          ?        0
Impacted Files Coverage Δ
src/server/accessors/ConfigurationExtend.ts 100% <100%> (ø)
src/server/managers/AppAccessorManager.ts 100% <100%> (ø)
src/server/accessors/Reader.ts 100% <100%> (ø)
src/server/accessors/SchedulerRead.ts 22.22% <22.22%> (ø)
src/server/accessors/Modify.ts 90% <33.33%> (ø)
src/server/accessors/SchedulerExtend.ts 40% <40%> (ø)

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 18d30f9...5235256. Read the comment docs.

Copy link

@mrsimpson mrsimpson left a comment

Choose a reason for hiding this comment

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

Looks quite nice to me, though very dependent on later. The interfaces and types look well designed. The biggest headache to me is i18n.

src/definition/accessors/IJobBuilder.ts Outdated Show resolved Hide resolved
src/definition/accessors/IJobBuilder.ts Outdated Show resolved Hide resolved
}

export class Schedule implements ScheduleData {
public static fromText(text: string): Schedule {

Choose a reason for hiding this comment

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

ahh, now seeing you included the factory method here. Then, two questions:

  • Why did you integrated it into the actual Schedule (and not a separate factory, except laziness ;) )?
  • Why did you have this wrapped in the JobBuilder as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  1. So people can easily generate a schedule outside of the builder.
  2. Makes the builder an all-in-one, trying to make things easy for developers.

src/definition/scheduler/Schedule.ts Outdated Show resolved Hide resolved
@rodrigok
Copy link
Member

rodrigok commented Nov 6, 2018

@graywolf336 is this preventing the jib to run multiple times when running rocket.chat in a cluster?

@rodrigok
Copy link
Member

rodrigok commented Nov 6, 2018

@graywolf336 do you think this needs to be defined only inside the configuration method? Would be nice to define cron jobs based on messages or slashcommands, I think this should be something in the app class context.

@graywolf336
Copy link
Contributor Author

@rodrigok Yes, it will only run the job once even when there are multiple instances of the App system running.

And it will be available to Apps all the time, not just at initialization time.

There is still a lot of work to do, hence the "in progress" label. The reason this pull request was created was to get feedback from people, such as what @mrsimpson provided. 🙂

Copy link

@dbrekelmans dbrekelmans left a comment

Choose a reason for hiding this comment

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

Looking forward to this being implemented! Would be very useful.

package.json Outdated Show resolved Hide resolved
import { IJob } from '../scheduler';
import { IJobBuilder } from './IJobBuilder';

export interface ISchedulerExtend {

Choose a reason for hiding this comment

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

I think this interface is missing some features.

You want to be able to unschedule jobs and get a list of scheduled jobs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, what I'm going to do is add a new accessor to to the modify stage to allow modification to the jobs. But if I get into it and that is not a fluid design or works in reality, then we will see how else we can work with this.

src/definition/scheduler/IJob.ts Show resolved Hide resolved
@dbrekelmans
Copy link

@graywolf336 Is there anything I can do to help you work on this feature? I'm not very familiar with the apps-engine (only played around a bit with creating an app), but I'm willing to dedicate some time to help you work on this.

@d-gubert
Copy link
Member

d-gubert commented Oct 7, 2019

@dbrekelmans hey! nice to know you're interested in helping us with this!

We're bringing this back up in our queue and will be dedicating time to the feature in the following weeks, and would definitely appreciate the help! We've updated the description to reflect what is still missing to get this published :)

Also, we switched to only supporting crontab style scheduling
as of right now. In the future we may support a form of
i18n scheduling. This decision was reached after we decided
we wanted this feature out now instead of another year from
now (aka two years after the feature was first attempted).
* user friendly since the list of job names will be visible
* to the server administrator.
*/
name: string;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thoughts to everyone watching this thread about requiring an id: string property? As right now the name: string is simply for displaying on the UI the list of jobs and a history of them. But if an App wants to cancel a job or view the job's history there is not a way to do it currently. My idea is to allow the App to define the property but if the app leaves it empty then a random one will be generated.

Copy link
Member

Choose a reason for hiding this comment

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

Couldn't we use the name for that? Prepend it with the appId and a colon and should be good to go IMO 😛

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For our internal usage, yes. But for Apps to query, no. Because what if they want the same name for a job that runs based upon something a user does but doesn't want that detail to show up in the job history and they want to query all of the jobs done by a user? That's why I'm considering an id..

Copy link

Choose a reason for hiding this comment

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

Because what if they want the same name for a job that runs based upon something a user does but doesn't want that detail to show up in the job history and they want to query all of the jobs done by a user?

I'm not sure I quite understand what you mean by this. Could you maybe give a small example?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let's say you only want one job to run but you have two internal jobs and their behavior is massively based upon a configuration. The setting is changed in the admin area and when that happens you want to replace the job, that way the admin isn't aware of the different types and only sees one job in the job history and that type of stuff. Does that make sense?

Choose a reason for hiding this comment

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

I don't understand why there would be one job running multiple internal jobs. Shouldn't that just be separate jobs then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Imagine a payroll or something. For auditing purposes there should only appear as one job in the log. But because payroll is an extremely complicated item, the developer wants to separate the logic out from one giant job into different ones. So internally there are several jobs by the same name that way it appears as one job. I know this is an example that is stretching it, but I do see some valid reasons for not having the name be unique.

Copy link
Member

Choose a reason for hiding this comment

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

gotta admit I didn't follow the use case either :/

Choose a reason for hiding this comment

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

I think I understand what @graywolf336 means.
IMO if an app wants to split one scheduled job into multiple parts, then that's something the app itself can solve and not something that should be solved by the scheduling API

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And that's why I'm think we probably should have an id for the jobs and not rely on the name 🤔

@@ -0,0 +1,35 @@
import { parseExpression } from 'cron-parser';
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dbrekelmans
Copy link

dbrekelmans commented Oct 8, 2019

Hey @d-gubert, I'm still interested in helping, but I'd need something concrete to work on. Maybe we can find something tomorrow. I just joined open.rocket.chat, so we could chat there if you'd like.

I'm definitely going to write a remind-me app once this API is available. If it's up to standards maybe it could serve as an example for people looking to use this API.

@graywolf336
Copy link
Contributor Author

@dbrekelmans what's your username on the oepn.rocket.chat server?

@dbrekelmans
Copy link

@graywolf336 it's dbrekelmans, same as my github name.

@sveatlo
Copy link

sveatlo commented Mar 27, 2020

Any progress on this? I need it desperately. The lack of a scheduler API is the last thing blocking me from completing a daily standup application for Rocket.Chat (like standup-raven for Mattermost), which in turn is the last bit I need to migrate the entire company to Rocket.Chat.
I am also willing to help with this merge request, but I'd need quite specific instructions about what to do, since my codebase knowledge is pretty much none at this point (I only tried creating like 2 rather simple applications). Let me know if I could help you.

@graywolf336
Copy link
Contributor Author

@sveatlo can you try out the current code base and get a feel for deploying an App using the current API? Then provide us feedback on it and ways we can improve?

@thassiov thassiov mentioned this pull request May 14, 2020
@thassiov thassiov linked an issue May 14, 2020 that may be closed by this pull request
@majklovec
Copy link

Any progress?

@cuonghuunguyen
Copy link
Contributor

I am looking forward to it :D

@graywolf336
Copy link
Contributor Author

Closing this out dated PR in favor of the new functionality that has been in the Apps Engine for a while now. :)

@graywolf336 graywolf336 deleted the scheduler branch November 30, 2021 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⏳ in progress Items which are currently a work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement Scheduler
8 participants