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

feature: Custom Business Calendar #4789

Open
grantith opened this issue Nov 25, 2024 · 5 comments
Open

feature: Custom Business Calendar #4789

grantith opened this issue Nov 25, 2024 · 5 comments
Assignees

Comments

@grantith
Copy link

My team is in finance and almost all of our workflows need to run on US market days only. I'm not seeing a smooth way to manage such a schedule in Windmill, other than maybe leveraging a trigger action in every workflow we configure but that does not feel very smooth for this.

I know there are ways this could be handled within each script/flow but we have no interest in mingling the orchestration within the code directly or muddying up the run history with "fake" instantiations.

I believe this might be the most clean within the existing scheduling interface and that it should allow thoughtful flexibility for the list of dates that a schedule will include.

Otherwise, if I'm missing an alternative approach available today please advise!

@rubenfiszel
Copy link
Contributor

How is a US market day defined ? What's the source of truth ?

@grantith
Copy link
Author

grantith commented Nov 25, 2024

@rubenfiszel I believe it needs to be customizable and the source of truth becomes the configuration or input for the schedule or calendar. A team may even need multiple calendars (one for each: equities markets, bond markets, US bank holidays, etc).

In our use case US market days are as our business/industry defines them, but another Windmill team should be able to configure their holiday list according to their business.

In our existing tool one can define an arbitrary amount of business calendars (with inclusion/exclusion dates i.e. holidays) which can then be attached to any schedule (along with a time specification).

@rubenfiszel
Copy link
Contributor

I think you want a blacklist of days to skip based on workspace-wide defined calendars. One issue is that those calendars would pretty annoying to set by hand and are much better done in code. I understand the need to not mix your business logic with your scheduling logic but seems to me what you want is to run a "skip step" script prior to running the real script/flow that would return a boolean if one should the skip the flow on that date. If it can be picked in the schedule editor directly then it would still be convenient.

We can offer that as an EE feature.

@grantith
Copy link
Author

@rubenfiszel I agree setting by hand is not ideal.

To clarify further, my hope for such a feature would include..

  • The blacklist should be reusable and centrally configurable.
  • The blacklist can be configured in a way that doesn't require manual selection (file input, list, script, etc).
  • The usage of the blacklist should be able to be toggled within a schedule interface.
  • Any usage of the feature would not instantiate a run for the script/workflow via run history or related metrics.

The skip step approach you mention may be adequate. Though having this aspect of the scheduling logic represented within each flow DAG feels noisy compared to allowing the implementation to be tucked within the rest of the schedule config only.

Thanks for your consideration. We are planning to trial EE & windows workers in the next month or two. Very impressed so far.

@rubenfiszel
Copy link
Contributor

To be clear, it wouldn't be in each flow DAG, it would be specific to each schedule, similar to how you can set the error handler in every schedule. It would be a separate script that you wouldn't see from the run page or at least separately than full flows.

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

No branches or pull requests

2 participants