[bridge 4/n] SuiSyncer #15201
[bridge 4/n] SuiSyncer #15201
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Ignored Deployments
|
longbowlu
force-pushed
the
bridge-4-sui-syncer
branch
from
288956e
to
33f9b11
Compare
There was a problem hiding this comment.
A few comments about eth and sui syncer,
- It seems
ethersis being deprecated in favor ofalloy: https://docs.rs/ethers/latest/ethers/. Does this affect the usages here? - eth and sui syncer module can crash when fullnodes are disconnected. I'm not sure if it is better than retrying forever. E.g. even if the eth fullnode is down, in theory we should still be able to use the sui->eth quorum driver module?
- A metric for
last_finalized_blockin eth syncer could be useful.
|
|
||
| /// Map from contract address to their start block. | ||
| pub type SuiTargetModules = HashMap<Identifier, TransactionDigest>; |
There was a problem hiding this comment.
For a new contract, what would be the TransactionDigest?
There was a problem hiding this comment.
it could be any transaction digest that happens before the new contract's existence - it's not very intuitive, i hope we have checkpoint as the cursor
| sui_client.query_events_by_module(PACKAGE_ID, module.clone(), next_cursor), | ||
| Duration::from_secs(10) | ||
| ) | ||
| .expect("Failed to query events from sui client after retry"); |
There was a problem hiding this comment.
What is the reason for crashing instead of retrying (e.g. via continue) here?
There was a problem hiding this comment.
we retried with retry_with_max_delay a few lines above with 10s max time out. Do you think we should indefinitely retry to perhaps increase the max timeout latency?
There was a problem hiding this comment.
Ok to use a larger timeout for now.
The deprecation notice was up for two days when i chose the crate. I had a very brief look at alloy and feel it's not mature enough for us to adopt (may have some unnecessary hiccups. Some comments in gakonst/ethers-rs#2667 alloy have similar concerns. Ethers also have better docs.
I need to think more about it. Initially I wanted to panic because it's easier to spot the disconnectivity. Is it ok that we use a larger timeout latency for now and add a TODO to change this behavior if needed? @mwtian
|
longbowlu
force-pushed
the
bridge-4-sui-syncer
branch
from
33f9b11
to
0629d81
Compare
longbowlu
force-pushed
the
bridge-4-sui-syncer
branch
from
0629d81
to
f5029dd
Compare
|
|
||
| async fn run_event_listening_task( | ||
| // The module where interested events are defined. | ||
| // Moudle is always of bridge package 0x9. |
There was a problem hiding this comment.
Where are we adding a new package?
| interval.tick().await; | ||
| // TODO reconsider panic, should we just log an error and continue the loop? | ||
| let events = retry_with_max_delay!( | ||
| sui_client.query_events_by_module(PACKAGE_ID, module.clone(), next_cursor), |
There was a problem hiding this comment.
For query_events_by_module, do you know if it's returning events emitted in the module code, or emitted when calling an entry function in the module code?
| .expect("All Sui event channel receivers are closed"); | ||
| // Unwrap: `query_events_by_module` always returns Some `next_cursor` | ||
| // If the events list is empty, `next_cursor` will be the same as `start_tx_digest` | ||
| next_cursor = events.next_cursor.unwrap(); |
There was a problem hiding this comment.
Still a bit fragile to depend on a fullnode behavior. We should not unwrap if it's trivial not to.
## Description Implements `SuiSyncer` that periodically pulls from Sui to fetch Bridge related events. ## Test Plan How did you test the new or updated feature? --- 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 Implements `SuiSyncer` that periodically pulls from Sui to fetch Bridge related events.
|
Hi @longbowlu, happy to announce Alloy |
Description
Implements
SuiSyncerthat periodically pulls from Sui to fetch Bridge related events.Test Plan
How did you test the new or updated feature?
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)
Release notes
Implements
SuiSyncerthat periodically pulls from Sui to fetch Bridge related events.