Update cosmos events

[NicolasMahe]

closes #1747

• Use the default cosmos event message, as it should, in the module handler of each module
• Create dedicated events for each module. Call them in the keeper functions of each module
• Update the rest of the codebase. Deleted the not really useful stream function from RPC client to allow more flexibility (it forced the event to hash a hash attribute)

Improved event filtering

The new events allow creating queries that exactly match resources we want.
Instead of having to filter possible matching resources, now you should be able to write queries that match them perfectly.
Example that match execution for a specific executor and status (source):

query := fmt.Sprintf("%s.%s='%s' AND %s.%s='%s'",
	executionmodule.EventType, executionmodule.AttributeKeyExecutor, runnerHash.String(),
	executionmodule.EventType, executionmodule.AttributeKeyStatus, execution.Status_InProgress.String(),
eventStream, err := s.rpc.Subscribe(ctx, subscriber, query, 0)
)

Events list

message

All modules emit an event type message when they received a destined message with the following data:

key	value
module	module name, eg service
sender	signer of the tx, eg mesgtestXXX
action	msg'stype. managed by the base app, eg create

service

The module service emits an event type service when a service has been created with the following data:

key	value
action	created
hash	service's hash
address	service's address

runner

The module runner emits an event type runner when a runner has been created or deleted with the following data:

key	value
action	created OR deleted
hash	runner's hash
address	runner's address
instance	runner's instance hash

process

The module process emits an event type process when a process has been created or deleted with the following data:

key	value
action	created OR deleted
hash	process hash
address	process address

ownership

The module ownership emits an event type ownership when an ownership has been created or deleted with the following data:

key	value
action	created OR deleted
hash	ownership hash
resource_hash	ownership's resource hash
ressource_type	ownership's resource type
ressource_address	ownership's resource address

instance

The module instance emits an event type instance when an instance has been created with the following data:

key	value
action	created
hash	instance's hash
service	instance's service hash

execution

The module execution emits an event type execution when an execution has been proposed, created or when a result has been submitted with the following data:

key	value
action	proposed OR created OR completed OR failed
hash	execution's hash
address	execution's address
executor	execution's executor hash
process	optional execution's process hash
instance	execution's instance hash

[antho1404]

Everything is good, the execution's events could be improved, now the behavior is a bit weird, I would recommend sending an event for every single mutation of the execution so

• x events for proposed
• 1 event for created
• 0 or 1 event for completed
• 0 or 1 event for failed

Based on your table:

key	value
action	proposed OR inProgress (I don't really like in progress could be better created) OR completed OR failed
hash	execution's hash
address	execution's address
status	execution's status
executor	execution's executor hash
process	optional execution's process hash
instance	execution's instance hash

[NicolasMahe]

Everything is good, the execution's events could be improved, now the behavior is a bit weird, I would recommend sending an event for every single mutation of the execution so

• x events for proposed
• 1 event for created
• 0 or 1 event for completed
• 0 or 1 event for failed

Based on your table:

key value
action proposed OR inProgress (I don't really like in progress could be better created) OR completed OR failed
hash execution's hash
address execution's address
status execution's status
executor execution's executor hash
process optional execution's process hash
instance execution's instance hash

Execution event updated to:

key	value
action	proposed OR created OR completed OR failed
hash	execution's hash
address	execution's address
executor	execution's executor hash
process	optional execution's process hash
instance	execution's instance hash

[antho1404]

tiny issue but maybe this should be done only when everything is ok so after we get the execution, before the Filter.Match

[NicolasMahe]

The filter match is based on the date of the execution, so even if it's not the right event, the data of the execution will be the same so the filter will work exactly the same way all the time.