TimerTool - a robust timer layer for motoko

Developers Language Support
1

We have released the first version of our TimerTool library: GitHub - PanIndustrial-Org/timerTool: A timer management tool for motoko.

mops add timer-tool

The TimerTool Class+ component enables the stable creation of both synchronous and asynchronous scheduled tasks that survive upgrades and that can have state parameters associated with handlers. It includes error handling, execution notification, and the ability to recover from network errors encountered during the async execution of timer code. We also provide an upgrade pathway incase the stored parameters of scheduled tasks need to be performed.

Use cases:

  • Schedule a wallet canister to check a price at a particular interval and execute a trade under certain conditions
  • Schedule the payout of tokens
  • Trigger processing of smart contract code in the future
  • Clean a particular item out of a cache

Example usage:

private func handleTransfer(actionId: ActionId, action: Action): ActionId {

  //retrieve expected type from candid
  
  let candidParsed : ?(Value, Nat)  = from_candid(action.params);
  let ?tupleVal = candidParsed else D.trap("unexpected type");
  let ?mapArray = tupleVal.0 else D.trap("not a valid icrc3 block");
  //todo: validate block with ledger
  let #Array(toArray) = getMapValue(mapArray, "to");
  let #Blob(to) = toArray[0];

  if(Principal.fromBlob(to) == Principal.fromActor(this)){
    //handel receiving payment
  };
  actionId;
};

timerTool.registerExecutionListenerSync(?"icrc1Transfer", handleTransfer);

public shared func notify_of_transfer(transferArgs: ICRC3.Value, index: Nat) : () {
  
  //delay processing for 5 minutes
  let actionId = timerTool.setActionSync<system>(Time.now() + (ONE_MINUTE * 5), {
    actionType = "icrc1Transfer";
    params = toCandid((transferArgs, index));
  });
};

Recurring events are also easy to setup. See the readme.

TimerTool is also the first commercial motoko component to participate in the Open Value Sharing ecosystem. The default behavior is: 1 XDR per month for up to 100,000 actions; 1 additional XDR per month for each additional 100,000 actions. Max of 10 XDR per month per canister, but we encourage users of the library to implement any OVS heuristic of their choice.

5 Likes