Use a large number of confirmations

In order to avoid messages from being stuck in cases when the BlockUpdater contract malfunctions for any reasons, the number of verifications in the call to the Ultra Light Node could be set to huge number, to ensure its success.

function _verify(
    bytes32 _blockHash,
    bytes32 _receiptHash,
    uint32 _srcEid,
    address _receiver,
    bytes memory _packetHeader,
    bytes32 _payloadHash
) internal {
    // ... 
    IReceiveUlnE2(receiverLib).verify(
        _packetHeader, 
        _payloadHash, 
-       uint64(blockConfirmation)
+       type(uint64).max
    );
}

Note that this particular solution (or any solution of this sort) is not the safest, as it goes against the verification of the number of confirmations, as recommended in ref↗ and should only be considered should the BlockUpdater be impaired for any reason.

Polyhedra Network provided the following response:

As you highlighted, the proposed solution of utilizing an exceptionally large number of confirmations, while intended as a workaround for scenarios where the BlockUpdater may malfunction, is fundamentally not secure. It is essential to address and rectify any issues with the BlockUpdater directly.

Relying on Oracles to push transactions with the maximum number of confirmations in the event of a BlockUpdater failure circumvents the essential verification process. This approach compromises the integrity of the transactions on the sending chain by not duly verifying them.

Therefore, we have decided not to implement the suggested modification. Ensuring the integrity of the verification process and the reliability of the BlockUpdater takes precedence, and we will focus on addressing the root causes of any issues with the BlockUpdater directly.