[Bug]: `findCheckpointHints` reverts after `NOT_FOUND` hint

[avsetsin]

Summary

In WithdrawalQueue.findCheckpointHints a single NOT_FOUND hint makes the next iteration revert, so the batch call fails instead of returning hints for the rest.

core/contracts/0.8.9/WithdrawalQueue.sol

Lines 298 to 311 in d5d9226

	function findCheckpointHints(uint256[] calldata _requestIds, uint256 _firstIndex, uint256 _lastIndex)
	external
	view
	returns (uint256[] memory hintIds)
	{
	hintIds = new uint256[](_requestIds.length);
	uint256 prevRequestId = 0;
	for (uint256 i = 0; i < _requestIds.length; ++i) {
	if (_requestIds[i] < prevRequestId) revert RequestIdsNotSorted();
	hintIds[i] = _findCheckpointHint(_requestIds[i], _firstIndex, _lastIndex);
	_firstIndex = hintIds[i];
	prevRequestId = _requestIds[i];
	}
	}

If _findCheckpointHint() returns 0 (NOT_FOUND), the code sets _firstIndex = hintIds[i] which becomes 0. On the next loop, _findCheckpointHint() is called with _start == 0 and reverts with InvalidRequestIdRange. This means one “not found” result breaks the whole batch.

Expected Behavior

If _findCheckpointHint() returns 0 (NOT_FOUND) for one request ID, the batch should continue and return hints for the remaining IDs without reverting.

Potential Impact

Low severity. This is a view helper, but it can break batch UX and integrations relying on this method.

Steps to Reproduce

• Create two requests but do not finalize them
• Call findCheckpointHints([unfinalizedRequestId, anotherUnfinalizedRequestId], 1, lastCheckpointIndex).

The first NOT_FOUND sets _firstIndex to 0, and the next iteration reverts with InvalidRequestIdRange.

Possible Solutions

Only update _firstIndex when the hint is not zero:

// ...
hintIds[i] = _findCheckpointHint(_requestIds[i], _firstIndex, _lastIndex);
if (hintIds[i] != NOT_FOUND) _firstIndex = hintIds[i];
// ...

Guidelines

• I agree to follow Code of Conduct.
• I have read Lido Contribution Guide.