Listener: Define the interfaces for all the functions in Listener

[deepesh-kn]

The scanner listener reads each and every block from the chain and looks for StakeRequested event for the given composer contract. Once the event is found it callbacks the facilitator with event data.
scanner listener keeps a record of the last block scanned so that it can resume the scanner listener from the same block height. For more details check the epic #1

The scanner listener can be for the origin and auxiliary chain.
The scanner listener should update the database tables.

This ticket is about defining the interfaces of all the functions in the scanner listener.

The proposed functions are provided for reference.
The implementer can think this in detail and can add/remove functions

We can call this as EventListner.

• constructor.
  - Accepts mosaic-config and facilitator-config.

  • Accepts Config object. (store in variable).
  • Accepts object that cointains {contractAddresss: [Event topics]}.
  • Creates DB object. (store in variable). (Still in discussion)

• function to scan the blocks in batches. (Start scan)

  • Accepts blockNumber as a parameter.
  • blockNumber is an optional param, if this is provided then the scanner listener will start scanning from that block, else it will start from the latest block.
  • Keep track of last block number that was scanned.

- [ ] function to update the last scanned block number.
- [ ] function to get transactions for the given block.
- [ ] function to get events from the given transaction.
- [ ] function to emit an event when StakeRequested event is found.

• function to stop the scanner listener (SIGTERM). (Update the ticket)

- [ ] function to updates stake_request table status. (create a new ticket for this.)

[jasonklein]

📶 😃!

Still, some questions (more about implementation, but here in case the answers impact the interfaces):

• blockNumber is an optional param, if this is provided then the scanner will start scanning from that block, else it will start from the latest block

Will this scanner make use of https://github.com/ostdotcom/ost-block-scanner? If yes, I note that the OST scanner also takes an optional endBlockNumber.

Will the scan function look at both origin and auxiliary chains when called or should the caller identify which chain?

function to get transactions for the given block.

function to get events from the given transaction.

Is the scanner meant to also be available for general purpose use? (This question applies to both functions, but more to the transactions getter than the events getter.) Will the scanner store more information than what is required for facilitating stake requests?

function to update the last scanned block number.

function to emit an event when StakeRequested event is found.

function to handle SIGTERM.

To confirm, the above functions are private?

[deepesh-kn]

📶 😃!

Still, some questions (more about implementation, but here in case the answers impact the interfaces):

• blockNumber is an optional param, if this is provided then the scanner will start scanning from that block, else it will start from the latest block

Will this scanner make use of https://github.com/ostdotcom/ost-block-scanner? If yes, I note that the OST scanner also takes an optional endBlockNumber.

We can take the code for our reference. It has many dependencies of other projects/packages, which may not be needed for our implementation.

Will the scan function look at both origin and auxiliary chains when called or should the caller identify which chain?

The mosaic-config has the origin chain, so the scanner will start for the origin chain only. The implementer can decide if the chain id has to be provided in the constructor.

function to get transactions for the given block.
function to get events from the given transaction.

Is the scanner meant to also be available for general purpose use? (This question applies to both functions, but more to the transactions getter than the events getter.) Will the scanner store more information than what is required for facilitating stake requests?

The scanner can be available for general purpose use, the functions can be implemented in the seperate class where it becomes generic and can be used at places other than scanner as well

The scanner will just scan for the StakeRequested event, it will have no idea why this event will be used. So in the future, more such events can be added. This will give the flexibility of the scanner being used at other places

function to update the last scanned block number.
function to emit an event when StakeRequested event is found.
function to handle SIGTERM.

To confirm, the above functions are private?

This will be private functions. (Implementer can decide)