[gql] events (eventConnection) on tx

[wlmyng]

Description

Use fetch_events for transaction

Test Plan

transactions/events.move

---

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.

Type of Change (Check all that apply)

• [ ] protocol change
• [ ] user-visible impact
• [ ] breaking change for a client SDKs
• [ ] breaking change for FNs (FN binary must upgrade)
• [ ] breaking change for validators or node operators (must upgrade binaries)
• [ ] breaking change for on-chain data layout
• [ ] necessitate either a data wipe or data migration

Release notes

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
mysten-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 4, 2024 9:24pm
sui-core	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 4, 2024 9:24pm
sui-typescript-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 4, 2024 9:24pm

3 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
explorer	⬜️ Ignored (Inspect)	Visit Preview		Jan 4, 2024 9:24pm
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Jan 4, 2024 9:24pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Jan 4, 2024 9:24pm

[wlmyng]

Note that the StoredTransaction keeps track of a serialized representation of all its events:

https://github.com/MystenLabs/sui/blob/0a4182d17651e5b4d496f8ca2fa4610362bcf9af/crates/sui-indexer/src/models_v2/transactions.rs#L36

So it would be better to implement this referencing that, instead of doing another DB roundtrip, if we can avoid it, but we can treat that as a follow-up.

Hmm.. not sure how I missed this, thanks for calling it out. I think I can update Event representation to have optional StoredEvent and required NativeSuiEvent

[amnn]

I think I can update Event representation to have optional StoredEvent and required NativeSuiEvent

I was just having a look at this -- there are quite a few rows in StoredEvent that are actually derived from the transaction block, so you may want to keep the representation of GraphQL's event the same (a StoredEvent) but provide a way to build one given a GraphQL transaction block and a native event, or just a plain StoredEvent.

[wlmyng]

I think I can update Event representation to have optional StoredEvent and required NativeSuiEvent

I was just having a look at this -- there are quite a few rows in StoredEvent that are actually derived from the transaction block, so you may want to keep the representation of GraphQL's event the same (a StoredEvent) but provide a way to build one given a GraphQL transaction block and a native event, or just a plain StoredEvent.

Astute observation! Yes exactly, StoredTransaction and the native event can recreate a StoredEvent. Verified in the indexer code that values such as timestamp_ms are the same between the Indexed -> Stored Transaction and Event. I will do this to keep things simple

[wlmyng]

Ready for another review. Figured it'd be easier to just do the "right" thing straight up (use serialized events on StoredTransaction)

[amnn]

Thanks @wlmyng, some small clean-ups for this here: #15577