Execute hooks of ethflow orders

[MartinquaXD]

Fixes: #3388

Description

Currently ethflow orders don't have their hooks executed. The reason is that ethflow orders don't get added to the order book via a REST API call which would execute the usual code paths. Instead the autopilot indexes events emitted from certain contracts and adds it to the orderbook that way. This executes a bunch of different code paths that actually didn't check the hooks at all.

Changes

• moved --hooks-contract-address into shared args because the autopilot now needs it too
• during ethflow event indexing we now fetch the associated appdata, parse it, and insert the trampolined hook interactions if there are any. This code is a bit awkward due to the existing abstractions. Ethflow orders are a special variant of the more generic "onchain" orders. The ethflow specific handler already inserts the necessary unwrap pre-interaction. Because the general appdata handling needs to happen in the general handler and not the ethflow handler we first need to check how many interactions were already inserted for a given order so we don't overwrite any interactions by accident. Because the majority of times there is only 1 ethflow order per tx and to keep the code simple I decided to fetch the appdata sequentially instead of in parallel.
• because ethflow orders can be reorged (as they originate from onchain transactions) we need to be able to overwrite interactions in the DB. To do that I needed to adjust the primary key of the interactions table to include the execution flag. The readme was updated accordingly.

How to test

I updated an existing ethflow e2e test to pass 1 pre and post hook in the appdata. The hooks set an allowance for the trader address. Because we use approval interactions we can easily see in which context the user passed interaction got executed.
If we didn't sandbox the interaction correctly the approval would be set by the settlement contract. But in our test we can see that the approval was given by the trampoline contract. This shows that we didn't introduce a security risk by accident with this fix.

[github-actions]

Reminder: Please update the DB Readme and comment whether migrations are reversible (include rollback scripts if applicable).
If creating new tables, update the tables list.
When adding a new index, consider using CREATE INDEX CONCURRENTLY for tables involved in the critical execution path.

---

Caused by:

• database/sql/V085__interactions_unique_constraint.sql

[mrnaveira]

Some clarifying questions to make sure I understand correclty:

1. By adding the interactions to the trampoline contract, the settlement contract does now execute the interactions. Was this the only piece missing to actually trigger order hook execution?
2. The trampoline contract does not need to differentiate between pre and post hooks, as it's only meant as a sandboxed execution, so it's the settlement contract that differentiates pre and post right?
3. Is the interactions table used for anything else other than keeping track?
4. You mention: "Because the general appdata handling needs to happen in the general handler and not the ethflow handler we first need to check how many interactions were already inserted for a given order so we don't overwrite any interactions by accident". This is related to the database interactions table changes I assume.

[MartinquaXD]

By adding the interactions to the trampoline contract, the settlement contract does now execute the interactions. Was this the only piece missing to actually trigger order hook execution?

The most important part is that we now add the interactions from the appdata in the interactions table for the respective order. This did not happen before. The fact that this interaction gets stored with the trampoline indirection just makes it secure (prevents stealing funds from the settlement contract).

The trampoline contract does not need to differentiate between pre and post hooks, as it's only meant as a sandboxed execution, so it's the settlement contract that differentiates pre and post right?

Yes, the settlement contracts takes an interactions argument here which is a list of 3 lists. Depending in which list an interactions gets passed (1st, 2nd, 3rd) it gets executed before, during or after the main settlement logic.

Is the interactions table used for anything else other than keeping track?

Currently the autopilot loads the interactions associated with an order from that table instead of re-parsing the appdata. In the long term it would be more correct IMO to do that instead of using the table. Although that would require ethflow orders to pass the wrapAll() interaction in the appdata which the autopilot currently adds automatically instead.

You mention: "Because the general appdata handling needs to happen in the general handler and not the ethflow handler we first need to check how many interactions were already inserted for a given order so we don't overwrite any interactions by accident". This is related to the database interactions table changes I assume.

Yes. Technically the ethflow specific stuff can modify any table. So anything the generic onchain order handler does afterwards needs to be "compatible" with the changes the specific handler did before. In this specific case that means we need to make sure that we don't overwrite any interactions (i.e. wrapAll()).

[mrnaveira]

Based on the answers before, this LGTM. Although it would be nice to add a test scenario of a failed hook execution.