You may see this for OTAA. Like EU868 LMIC first tries the default channels at some initial data rate that is configured in the device. This may very well be the fastest data rate available (SF7BW125). When all default channels fail, LMIC will decrease the data rate one step, and try again.
This is fine for an OTAA Join, as for such the node knows it should always receive a downlink for each uplink, so it knows when things failed. But for ADR, it may take as many as 96 uplinks to detect that no downlink was received. According to the 1.0.2 specifications:
4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl)
[…]
If an end-device whose data rate is optimized by the network to use a data rate higher than its lowest available data rate, it periodically needs to validate that the network still receives the uplink frames. Each time the uplink frame counter is incremented (for each new uplink, repeated transmissions do not increase the counter), the device increments an ADR_ACK_CNT counter. After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >= ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request bit (
ADRACKReq). The network is required to respond with a downlink frame within the next ADR_ACK_DELAY frames, any received downlink frame following an uplink frame resets the ADR_ACK_CNT counter.
In LoRaWAN 1.0.x, for most (if not all) regions, ADR_ACK_LIMIT is 64, and ADR_ACK_DELAY is 32. (In LoRaWAN 1.1, it’s a configuration.)
When a device detects it has missed an expected downlink then at worst it already had 96 uplinks not being received, or at best simply only missed the ADR-triggered downlink. It may want an aggressive strategy to ensure it might actually still be in range, or change its settings to get in range again. But according the the same specifications it seems that a certified device should only decrease its data rate by one step and wait another 32 uplinks:
If no reply is received within the next ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the end-device may try to regain connectivity by switching to the next lower data rate that provides a longer radio range. The end-device will further lower its data rate step by step every time ADR_ACK_DELAY is reached. The ADRACKReq shall not be set if the device uses its lowest available data rate because in that case no action can be taken to improve the link range.
Aside: the above is also why ADR-enabled devices that have trouble receiving downlinks will eventually end up at DR0.