Aggregate offer should include failure details

[vasco-santos]

An aggregate/offer can fail when SPs try to accept an aggregate. It can be for a few reasons, like when a commP for a CAR file that is part of the aggregate is wrong.

spade-proxy should issue a receipt for refused aggregate with the details of what failed to be added. This will enable web3.storage actor to create a new aggregate without the "bad content" and flag the bad content.

There is still open question on how we can get such details in spade-proxy:

• Can this info be queried from Spade Oracle?
  • Or do we have to expose an API for getting such details?
• Are there any docs on types of failures and how they look like?

[vasco-santos]

We need to specify a report API for this and propose to Spade team.

Known failures are:

• wrong commP
• could not fetch from URL
• timeout sealing deal (3 days after contract)

[vasco-santos]

Talking with @alanshaw , we should look into discussing if this Report API can not only tell us Failed items, but also when success happens. Having a Poll mode to check success via Oracle, but then a Push mode to receive failed items is not great. Better just do Pull or Push for both flows

[vasco-santos]

Talking with @anjor and @ribasushi , to have a pull mode we would need a tenant report-api that pulls from the Oracle and has an endpoint that SP can push to. Considering that this API would need to keep the state of the reports.

Let's figure out design soon

[vasco-santos]

there only 3 actual states for a proposal once it is signed by w3s or any other tenant:

• unknown
• deal-active
• time-to-activate missed

Also worth noting

• for reporting API, SPs reach out to us directly
• reporting failure is voluntary and we should make things as simple as possible for SPs
• if there was no report of failure, we will need to wait until time-to-active missed state happens. We can infer this by keeping track of StartEpoch in the proposal signed