fix sync crashing with constraint fails, refactor db queries, improve performance #23
Conversation
yeah i went back and forth on making it start from i'll update to make it start from |
| @@ -1,6 +1,7 @@ | |||
| use super::errors::*; | |||
|
|
|||
| const FARCASTER_EPOCH: i64 = 1609459200000; | |||
| const FARCASTER_EPOCH_IN_SECONDS: u32 = 1609459200; | |||
There was a problem hiding this comment.
What is the rationale behind keeping two variables here? Does it improves performance because I could imagine this function being called on every message received for validation?
| let logs = get_logs(self.provider.clone(), &filter).await?; | ||
| .topic0(vec![ | ||
| get_signature_topic(REGISTER_SIGNATURE), | ||
| get_signature_topic(TRANSFER_SIGNATURE), |
| } | ||
| Err(e) => { | ||
| warn!("Failed to process Transfer log: {:?}", e); | ||
| continue; |
There was a problem hiding this comment.
Have a doubt here. Shouldn't we return an error early if we fail to process a log? Why silence these errors?
| // Overriding the `signature` is required here due to a bug in ethers-rs that happens if we mention the `key` parameter as `Bytes` | ||
| // Since we have to use `H256` for `key`, the calculated signature doesn't match the actual signature for this event | ||
| #[derive(Debug, Clone, EthEvent)] | ||
| #[ethevent(signature = "0x09e77066e0155f46785be12f6938a6b2e4be4381e59058129ce15f355cb96958")] |
There was a problem hiding this comment.
How was it syncing before without overriding the sig? 🤔
| row.fid, | ||
| row.units, | ||
| hex::encode(&row.payer) | ||
| ); | ||
| values.push(value); | ||
| } | ||
| let query = format!( | ||
| "INSERT INTO storage_allocations (id, rented_at, expires_at, chain_event_id, fid, units, payer) VALUES {}", | ||
| values.join(", ") | ||
| "INSERT INTO storage_allocations (id, rented_at, expires_at, transaction_hash, log_index, fid, units, payer) VALUES {} {}", |
There was a problem hiding this comment.
Why are we not using query_builder anymore? I personally found that approach to be more readable.
This PR does a few things:
(transaction_hash, log_index)as primary key forchain_eventsand all related tablesethers-rsthat was leading toIdRegistryevents being unable to be parsed properlyprintln!statements