Failure Policy: Adds FailurePolicy API field to Job (#52)

* 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]>

Author: JoshVanL

.golangci.yaml

@@ -19,6 +19,9 @@ linters:
  - funlen
  - maintidx
  - containedctx
+ - mnd
+ - contextcheck
+ - err113
 linters-settings:
   goimports:
     local-prefixes: github.com/diagridio

README.md

@@ -27,7 +27,8 @@ func main() {
     TriggerFn: func(context.Context, *api.TriggerRequest) bool {
       // Do something with your trigger here.
       // Return true if the trigger was successful, false otherwise.
-      // Note, returning false will cause the job to be retried *immediately*.
+      // Note, returning false will cause the job to be retried according to
+      // the Jobs configurable FailurePolicy.
       return true
     },
   })
@@ -70,6 +71,11 @@ A Job itself is made up of the following fields:
   Optional.
 - `Payload`: A protobuf Any message that can be used to store the main payload of the job which will be passed to the trigger function.
   Optional.
+- `FailurePolicy` Controls whether the Job should be retired if the trigger
+  function returns false. `Drop` doesn't retry the job, `Constant `Constant` will
+  constantly retry the job trigger for a configurable internal, up to a configurable
+  maximum number of retries (which could be infinite). By default, Jobs have a
+  `Constant` policy, with a 1s interval and 3 maximum retries.
 
 A job must have *at least* either a `Schedule` or a `DueTime` set.