From 4c7578a277c3be6bfcc14bd1427e148e2b970a88 Mon Sep 17 00:00:00 2001 From: Boris Zbarsky Date: Wed, 15 Feb 2023 23:36:31 -0500 Subject: [PATCH] Make sure that we don't miss lookup result notifications. If we cross out min lookup time boundary between when we get a result and when the next ReArmTimer call happens, we want to make sure we don't end up waiting until our max lookup boundary. Fixes https://github.com/project-chip/connectedhomeip/issues/25049 --- .../AddressResolve_DefaultImpl.cpp | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp b/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp index 8140d0055f1b2e..a6b1bbde423dfb 100644 --- a/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp +++ b/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp @@ -61,6 +61,24 @@ System::Clock::Timeout NodeLookupHandle::NextEventTimeout(System::Clock::Timesta { return mRequest.GetMinLookupTime() - elapsed; } + + if (HasLookupResult()) + { + // We can get here if we got our result before our min lookup time had + // elapsed, but time has passed between then and this attempt to re-arm + // the timer, such that now we are past our min lookup time. For + // example, this can happen because the timer is a bit delayed in firing + // but is now being re-scheduled due to a cancellation of a lookup or + // start of a new lookup. Or it could happen because + // OnOperationalNodeResolved got called close to our min lookup time, + // and we crossed that line while going through mActiveLookups and + // before we got to calling ReArmTimer. + // + // In this case, we should just fire the timer ASAP, since our min + // lookup time has elapsed and we have results. + return System::Clock::Timeout::zero(); + } + if (elapsed < mRequest.GetMaxLookupTime()) { return mRequest.GetMaxLookupTime() - elapsed;