Fixing Monitor crashing regularly, small additional fixes

[kuzdogan]

The Monitors were crashing because we were throwing here

sourcify/services/monitor/src/ChainMonitor.ts

Lines 348 to 351 in 33cc02e

	throw new Error(
	"Failed to send contract to Sourcify server after multiple attempts.",
	);
	}

• Removes the throw
• Fixes the Avalanche RPC URLs
• Removes the launch.json built and run Monitor

[manuelwedler]

Why shouldn't we throw in that place?

[kuzdogan]

@manuelwedler Why should we? The monitor was able to successfully assemble the contract and send a request to the Sourcify server. It's a problem either on the network (probably this in our case) or an error of the Sourcify server. I don't think this should stop the Monitor from running.

We already log an error and actually we need to pay attention to that if there's an increase in errors. This wouldn't work now as we have plenty of these errors and need to fix it first.

[marcocastignoli]

I agree with @kuzdogan that the monitor should not be stopped for that error. When I implemented it I was confused by the try-catch at the top of the callstack

sourcify/services/monitor/src/ChainMonitor.ts

Lines 78 to 106 in 460fc8c

	start = async (): Promise<void> => {
	this.chainLogger.info("Starting ChainMonitor");
	try {
	if (this.running) {
	this.chainLogger.warn("ChainMonitor already running");
	return;
	}
	this.running = true;
	if (this.startBlock === undefined) {
	this.chainLogger.info(
	"No start block provided. Starting from last block",
	);
	this.startBlock = await this.sourcifyChain.getBlockNumber();
	}
	this.chainLogger.info("Starting polling", { block: this.startBlock });
	// Start polling
	this.pollBlocks(this.startBlock);
	// Listen to new blocks
	this.on(NEW_BLOCK_EVENT, this.processBlockListener);
	// Start logging block pause periodically
	this.startBlockPauseLogging();
	} catch (error: any) {
	this.chainLogger.error("Error starting ChainMonitor", { error });
	}
	};

Since this is an event being triggered, the error it's not catched. Instead of not throwing, I think it makes more sense to add another try-catch inside processBlockListener, so we have a central place in which all errors are catched inside the event.

[manuelwedler]

@manuelwedler Why should we? The monitor was able to successfully assemble the contract and send a request to the Sourcify server. It's a problem either on the network (probably this in our case) or an error of the Sourcify server. I don't think this should stop the Monitor from running.

We already log an error and actually we need to pay attention to that if there's an increase in errors. This wouldn't work now as we have plenty of these errors and need to fix it first.

Okay makes sense to me. I didn't understand that the monitor was crashing for it. Thanks for explaining.