HookModule update cannot handle address strings

[ltyu]

Context

Renzo specifies an aggregate of the defaultHook with their ProtocolFeel. The config specifies an address for the default hook.

hook:
    hooks:
      - "0x9e8fFb1c26099e75Dd5D794030e2E9AA51471c25"
      - beneficiary: "0x0e60fd361fF5b90088e1782e6b21A7D177d462C5"
        maxProtocolFee: "100000000000000000000"
        owner: "0x0e60fd361fF5b90088e1782e6b21A7D177d462C5"
        protocolFee: "158365200000000"
        type: protocolFee
    type: aggregationHook

Problem

When running warp apply and subsequently HookModule.update(), the Module attempts to redeploy the hook, despite no changes. This is due to the defaultHook address being compared to the derived version of it.

Additional Context

In updateExistingHook() of EvmERC20WarpModule, the EvmHookModule is initialized with actualConfig.hook

hyperlane-monorepo/typescript/sdk/src/token/EvmERC20WarpModule.ts

Lines 523 to 527 in f85c8c1

	const hookModule = new EvmHookModule(
	this.multiProvider,
	{
	chain: this.args.chain,
	config: actualConfig.hook,

Subsequently hookModule.update() is called with expectedConfig.hook, which get compared with a derived actual hookConfig (via this.read())

hyperlane-monorepo/typescript/sdk/src/hook/EvmHookModule.ts

Lines 153 to 167 in f85c8c1

	// We need to normalize the current and target configs to compare.
	const normalizedCurrentConfig = normalizeConfig(await this.read());
	const normalizedTargetConfig = normalizeConfig(targetConfig);
	// If configs match, no updates needed
	if (deepEquals(normalizedCurrentConfig, normalizedTargetConfig)) {
	return [];
	}
	if (
	this.shouldDeployNewHook(normalizedCurrentConfig, normalizedTargetConfig)
	) {
	const contract = await this.deploy({
	config: normalizedTargetConfig,
	});

The result will always result in a diff, because as we recall, the expected hook config contains an address (e.g. 0x9e8fFb1c26099e75Dd5D794030e2E9AA51471c25), and thus deploy a new hook.

Solution

• Consider adding a short circuit such that if a hook address is supplied, derive it to compare
• Alternatively, compare the address to the actual address
• Required: Add a unit test in the respective Module test

[nambrot]

This probably should just use @yorhodes 's new DefaultFaullbackRoutingHook #5405, wonder if that would fix that?