-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Market Actor Events #1471
Merged
aarshkshah1992
merged 8 commits into
integration/actor-events
from
feat/market-actor-events
Nov 3, 2023
Merged
Market Actor Events #1471
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
9f1d25a
publish deals event
aarshkshah1992 56b2a34
activate deals
aarshkshah1992 7763f9c
deal terminated
aarshkshah1992 8674a6b
deal completed event
aarshkshah1992 537232a
run CI
aarshkshah1992 405597c
rustfmt
aarshkshah1992 d750564
replace deal_id with id in market events
aarshkshah1992 fc96fb6
Merge branch 'integration/actor-events' into feat/market-actor-events
aarshkshah1992 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
use fil_actors_runtime::runtime::Runtime; | ||
use fil_actors_runtime::{ActorError, EventBuilder}; | ||
use fvm_shared::deal::DealID; | ||
use fvm_shared::ActorID; | ||
|
||
/// Indicates a deal has been published. | ||
pub fn deal_published( | ||
rt: &impl Runtime, | ||
client: ActorID, | ||
provider: ActorID, | ||
deal_id: DealID, | ||
) -> Result<(), ActorError> { | ||
rt.emit_event( | ||
&EventBuilder::new() | ||
.typ("deal-published") | ||
.field_indexed("client", &client) | ||
.field_indexed("provider", &provider) | ||
.field_indexed("id", &deal_id) | ||
.build()?, | ||
) | ||
} | ||
|
||
/// Indicates a deal has been activated. | ||
pub fn deal_activated(rt: &impl Runtime, deal_id: DealID) -> Result<(), ActorError> { | ||
rt.emit_event(&EventBuilder::new().typ("deal-activated").field_indexed("id", &deal_id).build()?) | ||
} | ||
|
||
/// Indicates a deal has been terminated. | ||
pub fn deal_terminated(rt: &impl Runtime, deal_id: DealID) -> Result<(), ActorError> { | ||
rt.emit_event( | ||
&EventBuilder::new().typ("deal-terminated").field_indexed("id", &deal_id).build()?, | ||
) | ||
} | ||
|
||
/// Indicates a deal has been completed successfully. | ||
pub fn deal_completed(rt: &impl Runtime, deal_id: DealID) -> Result<(), ActorError> { | ||
rt.emit_event(&EventBuilder::new().typ("deal-completed").field_indexed("id", &deal_id).build()?) | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
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:
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd avoid relying on "sentinel managed to do it" as evidence of anything:
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.