Are you saying ADR is telling you to keep using SF8, or only that the ADR response is received in RX1 on SF8?
When no changes are needed, ADR might not send a downlink. However, if it would never get any ADR command then the node would not be able to tell if its packets were received at all. To mitigate that, it should explicitly set the ADRAckReq field every now and then. According to the 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.
So, you’d need to verify if your uplinks has the ADRACKReq bit set every now and then.
In LoRaWAN 1.0, 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.
Beware that the Wiki says:
Only static nodes should use ADR. ADR can also be used by a mobile node that is able to detect when it is “parked” on a fixed spot.
That said, of course a node should be able to recover from losing connectivity, if only as gateways might go offline while the node doesn’t move. But given the ADR_ACK_LIMIT and ADR_ACK_DELAY totalling to 96 messages in LoRaWAN 1.0, it surely might take some time for the implementation to notice the link is dead.
But then: in your case, the dead link is reported and a re-join is initiated, so the above is probably merely for future readers…