Over the course of the life of a device (or battery), the time between the join and the first uplink should be a very small percentage - i.e. it should not happen very often. Is your device rejoining regularly?
We configured our services that sit on top of ChirpStack to queue the message until it can be successfully queued in ChirpStack. The same approach works for devices that have been registered but never joined, which also cannot queue downlinks in ChirpStack.
Or can you enqueue the DL during get_downlink_data_delay already?
Yes, there is a time-window between receiving the (first) uplink and when ChirpStack reads the queue, in which you can enqueue the downlink.
This is going to be easier in the future ChirpStack release I’m currently refactoring and cleaning up the code-base, which will also remove the limitation that you have to wait with the enqueue until the first uplink (nothing public yet).
A little background: the device keeps sending uplink messages successfully. I’ve waited for the “next uplink” and the error is persistent. I thought it could be related to the fact I was using replicas of the ns/ap server (based on wobcom / iot / Chirpstack Helm · GitLab), but them I scaled-down to one instance of each server and the error is still persistent.
Chirpstack App Server: 3.17.6
Chirpstack Net Server: 3.16.1
I can’t assure that it has joined after the last change I’ve made to the NS/AP instances: I’ve made several tests along with helm chat deployments options. However, I may say that all the tests were using the same DB (Postgres and Redis), so I’d expect that sessions keys would be properly stored. In fact, I’ve disabled such a device to force end-device rejoin mechanism and, after that, the problem was solved.