If you look at the base64 packet early in each dump, you’ll see that one is longer than the other.
If you look down at the end, you’ll see that the full one was sent at DR4, and the partial at DR0
Most likely, DR0 is so slow that sending the full data packet would require more time on air than considered polite, or even more than legally allowed in your location, so the sensor is instead sending an abbreviate packet instead. This gets particularly harsh at low data rates where just the LoRaWAN headers, framing, and checksum can take up a large amount of time.
What might be in the abbreviated packet (just the beginning, or everything packed in a different formate with less resolution) is entirely up to the designers of the sensors.
You need to find out what the shorter packet is actually supposed to contain and make sure your are decoding it properly.
Something that is a little unfortunate is that both packets seem to use the same fPort. Hopefully that means that the shorter one is just a truncated version of the longer; when I do distinct formats for low data rates I use a different port to let the decoder know it needs to handle them differently. Technically you could key off the expected packet length, but that feels like the kind of thing that might be more easily broken when someone makes a “trivial” change.