f: changed the action entity id and added tests

[jordaniza]

Description

Removes execution data from actions inside proposals. Adds manual testing that can be replicated inside other plugins then refactored.

An ID for generating actions has been created, this will be moved to the osx-commons-subgraph.

A second PR on OSx core is in progress which will make the necessary changes to the subgraphs.

https://www.notion.so/aragonorg/execResult-in-the-Subgraph-8879407b1d6f42f19530ef6bc06b3dc6#da8cb903e33342279d88725f068c9506

Task ID: OS-1162

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran all tests with success and extended them if necessary.
• I have updated the CHANGELOG.md file in the root folder.
• I have updated the DEPLOYMENT_CHECKLIST file in the root folder.
• I have updated the UPDATE_CHECKLIST file in the root folder.
• I have updated the Subgraph and added a QA URL to the description of this PR.

[novaknole]

Just to re-iterate over this:

Assume token-voting has its own UI separated from the osx core UI. Because of the fact that token voting subgraph doesn't store the execResult and whether the action was allowed to fail, In this case, what's your flow about how in token-voting UI, we show the each action's execResult and whether it was allowed to fail or not ?

I believe UI would need to do either one of the following:
1. call osx subgraph to fetch that exact, same proposal whose id corresponds to the same id that was created in token voting subgraph when proposal was created. With this, proposals must be stored with the same id in both plugin and dao and this would only require to make 1 extra API call.
2. call osx subgraph multiple times to fetch details about each action. This requires multiple calls which won't scale in the long run. If we go with this, that's when deterministic id for actions start to make sense, otherwise, if we ditch the (2), why would actions still need to have deterministic id ?

Question 1: I believe (2) doesn't scale as if there're 10 actions, making 10 api calls doesn't scale. So seems like we either go with Option 1 or there's another solution that you have on your mind. With option (1), there's no need to have actions deterministic, is there ? I might be missing a crucial detail, so would be great if you could mention here why action id needs to be unique for all different plugins.

The problem with both of the options above is that you currently assume that token voting is the one that calls dao to execute actions. The situation could change pretty easily if we assume that we have multiple stage scenario where token voting calls multisig to move to next stage and multi sig is the one that calls dao. In such scenario, inside token voting's subgraph, you would have a proposal with id of tokenVotingAddr + callId whereas when the executed event will be emitted, it will contain multisig address. Though, currently, token voting actually stores the dao address and it redirects the call to the dao directly without any intermediaries and this problem doesn't emerge for now, but for the plugins that won't behave the same as token voting, we definitely have this problem and not yet sure of the perfect solution.

[jordaniza]

Breaking down the challenges you outline:

1. Scaling of action calls. In the case of querying by Id. N actions = N+1 calls to fetch proposal + action items. As N -> 255, this would have a potential large, negative impact on performance.

2. A deterministic ID is challenging for multistage plugin workflows where the proposal plugin might not be the execution plugin.

3. Even if we stored proposal data inside OSx subgraphs, challenges in (2) will still be a problem in multistage or multi body governance.

As an alternative to the implementation abov, you suggest storing proposal data inside OSx subgraphs (noting the challenge in 3)

So on proposals being stored in OSx. I would push back for a couple of reasons:

1. Proposals are currently implemented on plugins. Conceptually this would make their data belong in the plugin. We could explore having a lightweight IProposal entity in OSx, which would give the plugin developer options to add additional fields in a separate subgraph, but I have other reasons why that might not be a good idea

2. Alternative execution methods. You already touch on this with multi body governance but it's a simpler problem than that IMO. You can grant execution permissions to anything in theory and they need not go through a proposal process. We'd then be adding a lot of conditional overhead to try and understand how to store different execution workflows and I think it is best to mirror the contract structure: keep the OSx subgraph to just store actions. it shouldn't care how they got there.

On the point about actions scaling. This is a very good one to be honest and I'm glad you raised it. For M users with N actions, calls scale at a rate of MxN. Here's a few options

1. Action containers on OSx core: these are in the original document as a consideration but I wasn't a huge fan as they introduced extra schema changes - maybe I need to rethink this. Containers would be stored on the DAO in place of actions and would be a many to many junction entity with metadata about the batch of actions. Each batch would have a unique ID. This would require additional schema changes on OSx core and we would need to think carefully about the ID for multistage governance.

2. Range query methods: we could advise clients to use filters over all actions instead of querying by action. This could be using the block number or the tx execution hash. Action IDs could be a filtering mechanism on the client side. Don't love this as it adds a lot of overhead to the UI and easy to get wrong.

Just coming back to deterministic IDs. I think in the event of multistage plugins we should defer a lot of heavy lifting to the plugin developer. The information we have inside Executed is enough (IMO) to give good guarantees on uniqueness for actions and are deterministic. If we went down the action containers route we could skip the action index.

If you had a complex, multistage plugin inside a subgraph, I would say you need to be ensuring that the id is of the execution plugin. This can be done with context variables, or potentially as part of the plugin proposal manager, which is the orchestration tool.

[jordaniza]

Ongoing discussions are in discord and notion