Yes, general problem with sequencing, no, there is no general solution, it’s very much situational.
Whilst we now have a potential 3 or so seconds to process an uplink and queue a response, this is ambitious and as we need to code for up or downlinks not arriving as expected, prone to some interesting failure modes.
This possibly indicates you are thinking of downlinks as a thing. Downlinks should be treated as an exception.
Everything and anything - but again, it sounds like a scheme predicated on downlinks being a common occurrence.
Having an uplink that expects a response should allow for “eventually” and then you embedded counters in to the message so it knows which uplink the downlink is responding to. But if you have a device that has some uplinks awaiting a response then the device isn’t a great candidate for LoRaWAN.
Again, devices should be highly unlikely to rejoin and as downlinks shouldn’t be prevalent, the conjunction of rejoin and pending downlinks should be rare.
No, but again it’s not its use case and as you aren’t using downlinks often, you should remember that you’ve queued one and you can see it in the console log. If you use the console to queue a downlink its because you are developing / testing. If you use downlinks, you really need an application / database that runs command & control and knows about the state of such things.
You can view the downlink messages via the CLI - which is the official preferred way to manage a deployment of devices.
ttn-lw-cli end-devices downlink list/clear/push/replace [application-id] [device-id] [flags]
The scenario I ran in to was a remote reboot that was sent as acknowledged by an enthusiastic tester. The device promptly rebooted, joined, hadn’t ack’d the downlink so rebooted, joined, hadn’t ack’d the downlink so rebooted, joined, hadn’t ack’d the downlink so rebooted, joined, hadn’t ack’d the downlink etc etc
It took a few goes to stop that from the command line, I think I ended up resetting the MAC state after it had joined but before it had uplinked so it didn’t have a session so didn’t connect so didn’t get the downlink. We’d then have wait for it to realise it had lost its join but as it was on a bench, the finger of reset was use.
It is the CLI command I have a test scheduled for to deal with this, to purge the downlink acks pending.
The command & control database for this device won’t allow ack’d reboot commands - or indeed any ack’d downlinks - we can either detect the change (say in uplink frequency) or we ack the change in the next scheduled uplink as long as it’s in a reasonable timescale (like the next couple of hours). Otherwise we send a short info uplink.