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

Enhanced Scheduling with Conditional Task Execution in Pterodactyl #5033

Open
1 task done
GGLinnk opened this issue Mar 15, 2024 · 4 comments
Open
1 task done

Enhanced Scheduling with Conditional Task Execution in Pterodactyl #5033

GGLinnk opened this issue Mar 15, 2024 · 4 comments
Labels
feature request A request for a new feature.

Comments

@GGLinnk
Copy link

GGLinnk commented Mar 15, 2024

Is there an existing feature request for this?

  • I have searched the existing issues before opening this feature request.

Describe the feature you would like to see.

Pterodactyl features a scheduling system resembling cron tasks, which operates based on real-time triggered events or intervals.

One drawback is the system's inability to initiate scheduled tasks if the host server starts after the specified time, limiting its effectiveness in certain scenarios.
For example, this limitation could lead to missed task executions when the host server reboots beyond the scheduled timeframe. Like a server startup.

Describe the solution you'd like.

A new feature could be added to Pterodactyl to enable conditional scheduling, allowing users to set specific criteria for task execution.
This would enhance planning capabilities by providing more flexibility and intelligence in automation workflows.

Additional context to this request.

No response

@GGLinnk GGLinnk added the feature request A request for a new feature. label Mar 15, 2024
@Boy132
Copy link
Contributor

Boy132 commented Mar 16, 2024

Duplicate of #4160

@GGLinnk
Copy link
Author

GGLinnk commented Mar 16, 2024

Duplicate of #4160

No, not really,
Unlike #4160, which suggests adding conditions to cron-based schedules, mine focuses on real-time permanent schedules.
This difference is crucial as it addresses missed task executions due to delayed server startups. By introducing conditional scheduling for real-time checks, users gain better control over task execution, enhancing flexibility effectively.

It's not only about conditional but mainly about absolute planning that it's respected whenever the main server is started after or before the planned task.

I may have not explained correctly though. Sorry about that.

@Zand3rsCode
Copy link

Zand3rsCode commented May 2, 2024

To be able to shedule force wipe (on rust server) with special commands we need too be able to use
[ "$(date +%m --date '7 days ago')" != "$(date +%m)" ]

0 19 * * 4 [ "$(date +%m --date '7 days ago')" != "$(date +%m)" ] &&

This job has a condition that checks if the month of the date 7 days ago is different from the current month, which will be true only on the first Thursday of the month.

Also same if it is a normal thursday. this is the only thing stopping me from doing more automations and make my life easier!

@GGLinnk
Copy link
Author

GGLinnk commented May 10, 2024

To be able to shedule force wipe (on rust server) with special commands we need too be able to use [ "$(date +%m --date '7 days ago')" != "$(date +%m)" ]

0 19 * * 4 [ "$(date +%m --date '7 days ago')" != "$(date +%m)" ] &&

This job has a condition that checks if the month of the date 7 days ago is different from the current month, which will be true only on the first Thursday of the month.

Also same if it is a normal thursday. this is the only thing stopping me from doing more automations and make my life easier!

This requires the server to be on.
I don't want to use hacks that I need to find here and there for x or y game server.
I need a native solution for real scheduling and not cron-based jobs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request A request for a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants