Feat: data bus #247
Feat: data bus #247
Conversation
…l-daemon into feat/data-bus-impl
| DATA_BUS_ADDRESS: 'DATA_BUS_ADDRESS', | ||
| DATA_BUS_PROVIDER_URL: 'DATA_BUS_PROVIDER_URL', |
There was a problem hiding this comment.
Do we support multiply chains?
There was a problem hiding this comment.
we only support this functionality on the depositor side, it aggregates messages from different data sources
There was a problem hiding this comment.
Consider adding this on council daemons side as well. It could be multiply rpc for one chain, or for different. Since the API is the same and we can deploy the contract with the same address on different chains this kind of fallback seems easy enough to implement.
| this.lastPingBlock = blockData.blockNumber; | ||
| await this.guardianMessageService.pingMessageBroker( | ||
| stakingModulesData.map(({ stakingModuleId }) => stakingModuleId), | ||
| blockData, | ||
| ); |
There was a problem hiding this comment.
Do we need to make sure that pings succeeded before updating the lastPingBlock?
| let dieTimer: NodeJS.Timeout | null = null; | ||
|
|
||
| const startDieTimer = (lastBlock: number) => { | ||
| if (dieTimer) clearTimeout(dieTimer); | ||
|
|
||
| dieTimer = setTimeout(async () => { | ||
| const logger = await getLogger(); | ||
| const error = new OnBlockError( | ||
| 'There were no new blocks for a long time', | ||
| lastBlock, | ||
| ); | ||
|
|
||
| logger.error(error); | ||
| process.exit(1); | ||
| }, MAX_TIME_WITHOUT_NEW_BLOCKS_MS); | ||
| }; |
There was a problem hiding this comment.
Would be a bit cleaner if dieTimer and startDieTimer were the property and method of the class. Would also make tests easier to write because we can spy on the timer.
| await this.mutex.lock(); | ||
| await this.dataBusClient.sendMessage(eventName, outputMessage); | ||
| } finally { | ||
| await this.mutex.unlock(); |
There was a problem hiding this comment.
unlock isn't async
| await this.mutex.unlock(); | |
| this.mutex.unlock(); |
| */ | ||
| public subscribeToEVMChainUpdates() { | ||
| const provider = this.provider; | ||
| this.provider.clone(); |
| const AppSchema = z.object({ | ||
| version: z.string(), | ||
| }); |
There was a problem hiding this comment.
the DataBus spec also includes name field
| import { TransactionResponse } from '@ethersproject/abstract-provider'; | ||
| import { DATA_BUS_REQUEST_TIMEOUT } from './data-bus.constants'; | ||
|
|
||
| export class DataBusClient { |
There was a problem hiding this comment.
Is the order of messages being sent important? What if they are reordered?
| async sendTransaction(eventId: string, dataBytes: string) { | ||
| const tx: TransactionResponse = await this.dataBus.sendMessage( | ||
| eventId, | ||
| dataBytes, | ||
| ); | ||
| await tx.wait(); | ||
| return tx; | ||
| } |
There was a problem hiding this comment.
Should we manually increase priority fee (up to certain limit relative to current base fee) during high network activity?
There was a problem hiding this comment.
Should we resend lost messages after a chain reorg?
No description provided.