This is very similar to #10, except that the KeyError is occurring on a different call.
I wonder if the Wahoo app has updated, as I've started encountering this with files exported from my Wahoo kickr and heart-rate monitor.
Traceback (most recent call last):
File "/Users/neil/tmp/fitdecode_bugreport/repro.py", line 4, in <module>
for frame in fit:
File "/Users/neil/.pyenv/versions/tmp/lib/python3.9/site-packages/fitdecode/reader.py", line 188, in __iter__
yield from self._read_next()
File "/Users/neil/.pyenv/versions/tmp/lib/python3.9/site-packages/fitdecode/reader.py", line 295, in _read_next
record = self._read_record()
File "/Users/neil/.pyenv/versions/tmp/lib/python3.9/site-packages/fitdecode/reader.py", line 440, in _read_record
self._add_dev_field_description(message)
File "/Users/neil/.pyenv/versions/tmp/lib/python3.9/site-packages/fitdecode/reader.py", line 774, in _add_dev_field_description
field_def_num = message.get_field('field_definition_number').raw_value
File "/Users/neil/.pyenv/versions/tmp/lib/python3.9/site-packages/fitdecode/records.py", line 183, in get_field
raise KeyError(
KeyError: 'field "field_definition_number" (idx #0) not found in message "field_description"'
This is very similar to #10, except that the KeyError is occurring on a different call.
I wonder if the Wahoo app has updated, as I've started encountering this with files exported from my Wahoo kickr and heart-rate monitor.
gzipped FIT file attached to reproduce: keyerror.fit.gz
I've worked around this by silently ignoring the KeyError:
but that is obviously a hack, rather than a proper fix!