Programmatic scheduling for templates

[dselman]

Allow the Ergo logic for a template to indicate to the host environment when the template should be next triggered.

[jeromesimeon]

Questions:

• What is the use case?
• When triggering a ~template~ contract instance, the caller need to pass a request, would the Ergo logic indicate the request? (as a kind of callback?)
• Any idea on syntax? 🙏 😃

[alexCatena]

I like this idea.When used in conjunction with a blockchain, It removes the necessity of having some a timer or timeout running on the chain code. I know some chain codes don't support timers.This would move the logic off chain and remove the necessity of having another service running just for the timer.

[dselman]

I propose that scheduled callbacks are expressed in terms of Intervals. This allows the Ergo logic to state that they need to be called back within a given time Interval. Please see https://www.joda.org/joda-time/key_interval.html for a description of time intervals.

concept Interval {
   o DateTime start
   o DateTime end
}

schedule myInterval;

Or:

schedule toInterval(myDateTime, myPeriod);

The schedule keyword allows the Ergo logic to define an Interval instance that can be retrieved by the host environment after processing of the incoming request has completed.

It is then the responsibility of the host environment to callback the clause/contract at the specified Interval. If the host environment cannot satisfy the Interval (e.g. the start of the interval is in the past, or the duration between the start and end of the interval is too short) the host environment may throw an exception.

The host environment may also use the interval information to sort/order the scheduled callbacks for many contract/clauses, potentially using different algorithms/queues/persistence for callbacks that are 5 years in the future with a period of 24 hours, vs intervals in 10 minutes with a period of 15 seconds.

Note: the Ergo code can only specific the next interval for a single callback. This ensures that the Ergo code never has to cancel callbacks, or modify them. It is the responsibility of the Ergo code to track progress through the contract and to set the next schedule as appropriate.

[dselman]

See also: https://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html

http://beru.univ-brest.fr/~singhoff/cheddar/publications/audsley95.pdf

[mttrbrts]

How does the host environment know how to callback the clause / contract? For example, what is the payload of the scheduled request? Which clause in a contract should the request be dispatched to?

[dselman]

Good question! I'll defer the second one to @jeromesimeon who has more insight into the "full contract" questions. I'd imagined that we will add a new modelled transaction for these callbacks. Something like:

transaction ScheduledRequest extends Request {
}

This would allow the template developer to handle ScheduledRequest as they handle other incoming request types.

[jeromesimeon]

A few (not very informed or clear, so bear with me) reactions:

• we should not try to do "real time" or "near real time" (which really means real time to people working on embedded systems)
• whose responsibility is it to ensure the scheduling makes sense (not in the past, not conflicting, etc.)
• whose responsibility is it to execute the call back?
• The call back should definitely indicate what has to be called (a request to be sent? a direct clause call?)
• I might model those as Obligations rather than ScheduledRequests, maybe... maybe something like:

event ScheduledRequestObligation extends Obligation {
  o Request request
  o Interval interval
}

or

event ScheduledCallObligation extends Obligation {
   o String clauseName
   o Params params
   o Interval interval
}

• We might not want to let programmers do those kinds of call back without a story on concurrency (e.g., what happens when two call backs overlap, is there locking? is there a different kind of scheduling?)

[jeromesimeon]

I would love to see a concrete use case... (scenario?)

[jeromesimeon]

A few more questions:

• Do we need a cicero-scheduler package for execution
• Is there Node.js npm package scheduler we can reuse or do we need to write our own
• How do we test this feature?

[mttrbrts]

Here is a schema proposal for automatic scheduled requests by templates.

These models should live in org.accordproject.cicero.runtime namespace at https://models.accordproject.org/cicero/runtime.html

import org.accordproject.time.Period from https://models.accordproject.org/[email protected]
import org.accordproject.time.Day from https://models.accordproject.org/[email protected]

abstract event ScheduledRequestEvent {
  o Request request
  o DateTime until optional
}

event PeriodScheduledRequestEvent extends ScheduledRequestEvent {
  o Period period  // period.unit has type PeriodUnit which is already constrained to a maximum granularity of 1 day. :+1: 
}

// In the future, we may also want to support other types of scheduled request, e.g.
event DateTimeScheduledRequestEvent extends ScheduledRequestEvent {
  o DateTime time
  o Period granularity
}

event DayOfWeekScheduledRequestEvent extends ScheduledRequestEvent {
  o Day day
}

event DayOfMonthScheduledRequestEvent extends ScheduledRequestEvent {
  o Number day
}

These events are emitted in the same way as obligations by contract logic. e.g.

emit PeriodScheduledRequestEvent
  request: Request { ... },
  period: Period { 
    unit: "weeks",
    amount: 2
  }
};