feat: TFHE operation events for coprocessor #269
Conversation
rudy-6-4
force-pushed
the
rudy/feat/event-tfhe-operation
branch
2 times, most recently
from
d4fc2c3 to
5185e76
Compare
| bench = false | ||
|
|
||
| [dependencies] | ||
| # workspace dependencies |
There was a problem hiding this comment.
Nit: These are both crates.io and workspace dependencies, maybe could split to separate sections.
There was a problem hiding this comment.
yes all versions will go to the root Cargo if no conflict and be pinned.
There was a problem hiding this comment.
postponed because no CI test to see if I introduce issues
rudy-6-4
force-pushed
the
rudy/feat/event-tfhe-operation
branch
from
5185e76 to
00893b7
Compare
| @@ -0,0 +1,663 @@ | |||
| { | |||
There was a problem hiding this comment.
is there a way to have an up to date version of these files always available ? so there is not need to have to copy or regenerate locally.
There was a problem hiding this comment.
That's what I am doing on the TxnSender part - I use the foundry-compilers crate:
foundry-compilers = { version = "0.13.0", features = ["svm-solc"] }
This way we can have the compiled contracts from source.
There was a problem hiding this comment.
Ok, I'll add that after merge. Should we version abi files so there are always avail ?
| pub start_at_block: Option<i64>, | ||
|
|
||
| #[arg(long, default_value = None)] | ||
| pub end_at_block: Option<u64>, |
There was a problem hiding this comment.
Why do we need to specify an end block? Is it for testing?
There was a problem hiding this comment.
It's in case someone want to do a manual catchup, like in prod some events are missing because of an ephemeral network issue or service down, you may want to only replay for a given period the events also it's to avoid letting the manual command up by mistake for an infinite time in case of manual call.
| contract_addresses: Vec<Address>, | ||
| stream: Option<SubscriptionStream<Log>>, | ||
| provider: Option<RootProvider<PubSubFrontend>>, // required to maintain the stream | ||
| last_seen_block: Option<u64>, |
There was a problem hiding this comment.
Do we need to persist the last seen block s.t. we start from there if we crash/stop?
There was a problem hiding this comment.
No it's was just for local logic, it's not persisted. Yes I was thinking of persisting a block number to the database but only after the events are written to the database and that block number could be used as the default starting block for this command-line.
No description provided.