Using the js sdk, given a file with records containing the field compressedSpeedDistance, if I try to decode it with expandComponents true (the default), it fails.
Decoder.#expandComponents will first create a speed field from compressedSpeedDistance. When it does so, it notices that speed should be expanded to enhancedSpeed, so it pushes speed onto this.#fieldsToExpand. Then it creates a distance field, and there's nothing more to do for that. Finally it tries to expand the speed field, and throws an error on this line, because speed doesn't exist in message (yet). It's been added to mesg, but that doesn't get appended to message until all component expansion has finished.
There's a simple fix - change that line to
And with that change, the file is successfully decoded. But there's still a problem. expandComponents added both speed and enhancedSpeed, but enhancedSpeed is only one tenth the value of speed (speed was correct). And the problem now is that when compressedSpeedDistance was expanded, it created a speed field with the same raw data as the speed part of compressedSpeedDistance. But the scaling factor for speed in compressedSpeedDistance is 100, while the scaling factor for speed itself is 1000.
Again, the fix isn't too hard. Currently, it always copies the rawFieldValue and creates a fieldValue by scaling it according to the source field. Instead it should create the fieldValue the same way, then reverse-transform the fieldValue based on the target to create the target's rawFieldValue.
I was going to create an issue/pull request, but then noticed that this file is auto-generated (and that the repo isn't configured for issues). So I'm guessing there's a master file which is used to generate all the different language decoders, and that's the one that needs to be fixed. And indeed, reading the python version, it appears to have exactly the same two bugs.
