bzbarsky-apple
commented
1 year ago @ArekBalysNordic I am not following the failure scenario. Is it possible to attach a log that shows the problem?
The intent of the current timers is that we should:
- Not even try to report results before the min time has elapsed, because we might as well wait for more complete results. This only makes sense if the min time is fairly short. 200ms was picked ... I am not sure how. @andy31415
- Stop trying to report results once the max time has elapsed; treat it as lookup failure. This max time used to be 15s, but that was too short, and it was raised to 45s.
So there are three ways a resolve can go:
- Any results we get before 200ms have elapsed we will end up in
Resolver::HandleAction, callNextAction,elapsed < mRequest.GetMinLookupTime()and we will do the "keep searching" thing as linked above. Then when the 200ms timer fires we will callHandleActionfrom the timer callback and report those results to our consumer. - Any results we get after the 200ms timer has elapsed we will end up in
Resolver::HandleAction, callNextAction, and report those results to our consumer immediately. - If we reach the 45s timer with no results, we fail out.
We should not be waiting until the 45s timer if we have results sitting around waiting to be reported.
ArekBalysNordic
Reproduction steps
Currently, the address resolve's minimum lookup time is set to the default value of 200 ms (https://github.com/project-chip/connectedhomeip/blob/master/src/lib/address_resolve/AddressResolve.h#L144). After performing OTA firmware update the nRF53 device working as MTD/FTD Thread device tries to send the confirmation to an OTA provider and does DNS resolve within ~200 ms. Sometimes, the time of DNS resolve is less than 200 ms, which causes continuing searching here: https://github.com/project-chip/connectedhomeip/blob/master/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp#L80. and the second attempt of sending confirmation to the OTA provider occurs after elapsing the maximum lookup time (45 seconds). That is a quite long time. That issue doesn't exist on SED/SSED Thread device types, because there the resolving time is much higher.
Steps to reproduce:
Log from FTD/MTD nRF53 lighting-app example:
Checking node lookup status after 197 msLog from SED nRF53 doorlock-app example:
Checking node lookup status after 1076 msBug prevalence
1-2 times a day
GitHub hash of the SDK that was being used
6ce0f901b50948280baaf56cb1778b58708e0eb2
Platform
nrf
Platform Version(s)
NCS 2.2.0
Anything else?
No response