Do the LNS always decode the payload or are there instances where is does not do it?
No, yes
I meant in the sense that I have associated (configured) a decoder in the console with the end device.
Barring decoder resource issues (which are infrastructural), I donât see a reason why a valid payload decoder will not be run successfully on a valid payload.
Does anyone have concrete examples/logs?
Per Nick
Detail is there is no guarantee/sla around TTN or associated functions. The decoder activity is overall server load dependent. If your decoder is too long it may time out (depending on its own needs and overall server load), and at one point (around V2-V3 transition IIRC) they (TTI) introduced a limit on how long the decoder could be as a block of code - too tight to start with they then relaxed it a little as caused too many problems. If server is heavily loaded even a âshortâ decoder may not execute or complete in time and may drop - no sla remember ;-).
Best practice, therefore, is think of the decoder as a nice to have and debugging tool and look to exfiltrate your payloads to you own external database, under your own control and servers/cloud and process/decode/manipulate and manage from there - keeping e.g. Storage integration (again not guaranteed) as a short term buffer and occasional assist if needing to recover a recently (few hours only) missed message, with the decoder helping locally and pehaps to pass on to other integrations (e.g. cayenne dashboard) etc. Often these will not need a local decoder 1st as the decoder can be loaded there or may be a standard item for them (e.g. I have original Semtech/iMST LoRaMOTEs that for the love of me I cant find a decoder to plug into TTN console, but which is then decoded happily at Cayenne as they have the decoder in their own repository)
Answer remains the same.
Assuming youâve tested it. 
Ha, sure, fricking thousands of them, most were on v2 towards the end but it happens on v3 as well - all it means for me is that a test uplink doesnât get in to a test database. All production stuff is put in the database and then decoded at âmyâ end - which means I can go back & decode packets after a client has changed their payload in firmware but not the decoders in the infrastructure.
So the standard reply here is âitâs a convenience functionâ - because there is nothing anyone can do if the perfect storm of incoming uplinks that have to pass through the messiest payload formatting JavaScript ever hacked to gather by random vendors who get their C programmers to do it comes along, sure, things time out.
I mourn the day that the PF size was so dramatically increased - it let all those hackers off the hook.
IIRC it was big to start withâŚthen they tried to limit - but too many things broke and too many complained so some relaxation - but not back to how big it used to be - perhaps that is why you see fewer problems (but still see them) than was the case under V2âŚ?
Or when you get an uplink via a WebHook, the only sane way to receive, and it detects that the f_cnt is out of sequence, a sub-process is triggered that looks to retrieve the missing uplink(s) from the Storage Integration.
This occurs so rarely that testing that code is a mess - typically I have to setup a test server so I can turn off the web server running on it to miss a few uplinks. But itâs worth it for those odd moments when something glitches or the database ends up with a field missing whilst someone is hacking on the decoder on the live system.
1 Like
Probably, but I donât class them as a problem, they are just part of the landscape. I donât even monitor for them as there is nothing anyone can do without TTI adding more servers âjust becauseâ.
My FireHose console can decode using the same PF so Iâve plenty of options. If the streams didnât disconnect I could add a couple of graphs and take a dashboard feed from the console output. And then add storage integration as a backstop for missing uplinks. But that would put an un-natural load on the whole lot, rather like those mobile apps that query storage without caching any local copies âŚ
I would still like concrete examples to be able to be certain that this is only a JS decoding engine resource issue.
All we get is the uplink without the decoded element - leaving the console window open wonât work as it will be a miracle / make-work to detect one & then ferret it out the log.
The best I can do is to add a flag to records in my dev databases if thereâs no decoded payload but Iâm not pushing through the volume to capture examples with any statistical reliability. And then youâd have to grab the logs at your end to see whatâs what.
All the other discussion aside, whatâs up?
So essentially not a issue for years, since V2.
As with the hand full of end devices I have, stuck in strange places, working on high load gateways (borrowed one, more on this in a few days, thank you sir for your kind assistance) I have never seen it.
Gateways have no bearing on the matter - itâs all about the load on the TTN LNS.