So what’s the situation since you disabled the confirmation?
There are a several moments when an ADR request is scheduled or sent:
The initial ADR Request (for US915 and AU915). This is sent immediately after join and is mainly used to set the channel mask of the device. This one is a bit tricky, because we don’t have enough measurements for setting an accurate data rate. To avoid silencing the device, we use an extra “buffer” of a few dB here. This request is only needed with pre-LoRaWAN 1.1 on our v2 stack. With LoRaWAN 1.1 devices on our v3 stack, we can set the channel mask in the JoinAccept message. ABP devices pre-LoRaWAN 1.1 will only get this message once, if they reset after that, they won’t get the message again; this issue is also solved by LoRaWAN 1.1.
Reading the above (emphasis mine) I’d guess it would not need an uplink first, but then: the node will not be listening after receiving the Join Accept, so TTN can indeed only piggy-back the ADR on a downlink after the first uplink. Like @UdLoRa wrote: click the downlinks to see the details. If you have access to the gateway’s Traffic page in TTN Console, then check that one too. Maybe given the actual payloads we can you more. (Maybe the ADR is in the Join Accept?)