Market Actor Events #1471
Market Actor Events #1471
Conversation
aarshkshah1992
changed the base branch from
master
to
integration/actor-events
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## integration/actor-events #1471 +/- ##
===========================================================
Coverage ? 91.09%
===========================================================
Files ? 151
Lines ? 28169
Branches ? 0
===========================================================
Hits ? 25661
Misses ? 2508
Partials ? 0 |
actors/market/src/emit.rs
Outdated
| .typ("deal-published") | ||
| .field_indexed("client", &client) | ||
| .field_indexed("provider", &provider) | ||
| .field_indexed("deal_id", &deal_id) |
There was a problem hiding this comment.
I think just just "id" is sufficient as a concise key here, and in the events below. We used "id" for allocations and claims in verifreg.
| &EventBuilder::new() | ||
| .typ("deal-published") | ||
| .field_indexed("client", &client) | ||
| .field_indexed("provider", &provider) |
There was a problem hiding this comment.
@Stebalien for a second opinion, I suggested it might be worth including these fields since the deal ID is generated by the market actor, so a caller can't know what ID to filter for ahead of time. Many watchers will be interested in a small subset by party, and can avoid state inspection for most unwanted events with these fields.
However, by this logic we should also add client and provider to the verified allocation event too.
There was a problem hiding this comment.
- Are we not including the deal label and/or CID? That seems like the more important identifier.
- Regardless, including the provider/client definitely make sense here.
- For the verified allocation event, I haven't thought enough about those to be sure? My guess is that the clients will want to track them (e.g., in a wallet), so including the client's ID is likely a good idea (at the very least).
Personally, I'd just include all fields we think might be relevant, then benchmark to make sure we haven't increased gas fees by too much.
There was a problem hiding this comment.
See filecoin-project/FIPs#754 (reply in thread) for why we're not including all the fields that might be relevant. Extending that discussion is still welcome.
There was a problem hiding this comment.
+1 to @Stebalien's idea of atleast including the client and provider to the events as well and then revisiting them after gas costs benchmarking. The UX will be much better if clients can reduce state lookups for events that have nothing to do with what they're interested in.
There was a problem hiding this comment.
Yeah, I guess I'm not exactly being consistent here (I think I was mostly focused on the discussion around identifying the event type).
I think we do want to include the minimum amount of information necessary to:
- Identify the event (so we can query for more information).
- Determine if the event might be interesting (usually just the IDs of the parties involved). This may significantly decrease complexity/costs for developers.
At first blush, I wouldn't include things like amounts because they can be queried. However, I'm not entirely sure about that because queries:
- Can only only see the state between top-level messages.
- Can only efficiently see the state between tipsets.
E.g., if a token is transferred multiple times within a single top-level message, being able to query the state isn't sufficient.
So, really, there's a third item: Any information the user might not be able to accurately and/or efficiently query for.
There was a problem hiding this comment.
Let's just do the parties involved for now. In the absence of events, tools like Sentinel have been able to calculate state changes by comparing before and after states.
There was a problem hiding this comment.
tools like Sentinel have been able to calculate state changes by comparing before and after states.
I'd avoid relying on "sentinel managed to do it" as evidence of anything:
- Sentinel mostly cares about the state of the system, not the individual operations. People who work with tokens, etc., care about the individual transfers.
- Sentinel actually had undecidable edge-cases (e.g., why did a sector terminate).
- Sentinel relies on, e.g., the fact a user can't terminate and compact in a single top-level message. That kind of guarantee will eventually disappear as we allow more and more on-chain programmability.
- Building and maintaining Sentinel was quite a bit more painful than it would have been if we had had proper events.
That doesn't mean we should just throw everything we can in every event (we can always add more information later), just... avoid using sentinel as evidence.
For #1464 .
This PR contains Market Actor events for the following deal lifecycle events:
We do not emit events for expired deals i.e. deals that have been published but not activated by their start epoch as that only ever happens in the cron job.