Skip to content

Conversation

JoshVanL
Copy link
Contributor

No description provided.

cicoyle
cicoyle previously approved these changes Sep 24, 2024
Copy link
Contributor

@cicoyle cicoyle left a comment

Choose a reason for hiding this comment

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

+1 - I really like this addition, it is definitely needed. It will make the system more resilient and robust. I wonder if it might make sense to have a global scope people could set for all jobs rather than on a per job basis? Or even a per job type setting? Might be interesting and less granular than a per job basis. Just something I thought of that could be an add on to this

Copy link
Member

@mikeee mikeee left a comment

Choose a reason for hiding this comment

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

+1 lgtm, just a question on defaults/where a policy is unset

Co-authored-by: Mike Nguyen <[email protected]>
Signed-off-by: Josh van Leeuwen <[email protected]>
@cicoyle cicoyle mentioned this pull request Oct 1, 2024
22 tasks
@mikeee mikeee self-requested a review October 2, 2024 15:29
@artursouza
Copy link
Contributor

+1 binding

1 similar comment
@yaron2
Copy link
Member

yaron2 commented Oct 3, 2024

+1 binding

JoshVanL added a commit to JoshVanL/go-etcd-cron that referenced this pull request Oct 4, 2024
Based of dapr/proposals#66

Adds a `FailurePolicy` option to the `Job` API to allow re-triggering
job which are marked as failed by the caller. Adds two types of policy;
`Drop` and `Constant`. `Drop` has no retry policy, `Constant` will
constantly retry the job trigger for a configurable delay, up to a
configurable maximum number of retries (which could be infinite).

Note that the failure policy retry cadence has no effect on the actual
Job schedule, meaning if a job was to be retired and eventually
succeeded, the Job would continue to trigger at the origin configured
schedule.

By default, all Jobs will have a `Constant` policy with a delay of 1s.

Signed-off-by: joshvanl <[email protected]>
JoshVanL added a commit to JoshVanL/go-etcd-cron that referenced this pull request Oct 14, 2024
Based of dapr/proposals#66

Adds a `FailurePolicy` option to the `Job` API to allow re-triggering
job which are marked as failed by the caller. Adds two types of policy;
`Drop` and `Constant`. `Drop` has no retry policy, `Constant` will
constantly retry the job trigger for a configurable delay, up to a
configurable maximum number of retries (which could be infinite).

Note that the failure policy retry cadence has no effect on the actual
Job schedule, meaning if a job was to be retired and eventually
succeeded, the Job would continue to trigger at the origin configured
schedule.

By default, all Jobs will have a `Constant` policy with a delay of 1s.

Signed-off-by: joshvanl <[email protected]>
artursouza pushed a commit to diagridio/go-etcd-cron that referenced this pull request Oct 14, 2024
* Failure Policy: Adds FailurePolicy API field to Job

Based of dapr/proposals#66

Adds a `FailurePolicy` option to the `Job` API to allow re-triggering
job which are marked as failed by the caller. Adds two types of policy;
`Drop` and `Constant`. `Drop` has no retry policy, `Constant` will
constantly retry the job trigger for a configurable delay, up to a
configurable maximum number of retries (which could be infinite).

Note that the failure policy retry cadence has no effect on the actual
Job schedule, meaning if a job was to be retired and eventually
succeeded, the Job would continue to trigger at the origin configured
schedule.

By default, all Jobs will have a `Constant` policy with a delay of 1s.

Signed-off-by: joshvanl <[email protected]>

* Linter

Signed-off-by: joshvanl <[email protected]>

* Rename `Constant` FailurePolicy `delay` to `interval`

Signed-off-by: joshvanl <[email protected]>

---------

Signed-off-by: joshvanl <[email protected]>
JoshVanL added a commit to JoshVanL/go-etcd-cron that referenced this pull request Oct 15, 2024
Based of dapr/proposals#66

Adds a `FailurePolicy` option to the `Job` API to allow re-triggering
job which are marked as failed by the caller. Adds two types of policy;
`Drop` and `Constant`. `Drop` has no retry policy, `Constant` will
constantly retry the job trigger for a configurable delay, up to a
configurable maximum number of retries (which could be infinite).

Note that the failure policy retry cadence has no effect on the actual
Job schedule, meaning if a job was to be retired and eventually
succeeded, the Job would continue to trigger at the origin configured
schedule.

By default, all Jobs will have a `Constant` policy with a delay of 1s.

Signed-off-by: joshvanl <[email protected]>
JoshVanL added a commit to diagridio/go-etcd-cron that referenced this pull request Oct 15, 2024
Based of dapr/proposals#66

Adds a `FailurePolicy` option to the `Job` API to allow re-triggering
job which are marked as failed by the caller. Adds two types of policy;
`Drop` and `Constant`. `Drop` has no retry policy, `Constant` will
constantly retry the job trigger for a configurable delay, up to a
configurable maximum number of retries (which could be infinite).

Note that the failure policy retry cadence has no effect on the actual
Job schedule, meaning if a job was to be retired and eventually
succeeded, the Job would continue to trigger at the origin configured
schedule.

By default, all Jobs will have a `Constant` policy with a delay of 1s.

Signed-off-by: joshvanl <[email protected]>
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

Successfully merging this pull request may close these issues.

5 participants