RoutineBuilder.build() silently swallows a real parse failure, emits
6 of 220 routines in a real test project come out with — an empty, invalid type — instead of their real type.
Root cause, precisely: in elements.py, RoutineBuilder.build():
python
try:
r = RxGeneric.from_bytes(results[0][3])
except Exception as e:
return Routine(results[0][0], results[0][0], "", [])
For these 6 routines, that call throws:
EndOfStreamError requested 1432966489 bytes, but only 328 bytes available
— a length-prefixed field somewhere in the Kaitai struct is reading a value that isn't a real length, requesting well over a billion bytes from a 328-byte remainder. That's a genuine structural parse failure on these routines' own header records, not a downstream content issue — and it's currently caught and silently discarded rather than surfaced.
A note on what I didn't assume: my first instinct was that all 6 would be the same routine type (since 5 of them are), so I nearly "corrected" the empty Type to a guessed value. Checked before doing that, and one of the 6 is actually a different type entirely from the other 5 — so whatever's structurally different about these routines' header records isn't type-specific. Glad I checked rather than shipped that guess; mentioning it in case it's a useful data point for narrowing down the cause.
Possibly relevant: in the real L5X, the 5 same-typed routines all carry nearly identical EditedDate timestamps (within about 80ms of each other) — looks like a single batch save/edit operation. Might be that a specific edit action leaves the on-disk record in a shape RxGeneric doesn't expect yet.
Suggested improvement, regardless of the root cause being found: at minimum, don't silently swallow the exception — log it or surface it somehow, so a user knows a routine's type/content genuinely failed to parse rather than assuming an empty routine is just... empty.
Diagnosed with the help of Claude (Anthropic) while building a downstream tool against this library — flagging that in case it affects how you'd like to handle this report. Happy to answer questions or share the specific record bytes if that'd help track it down.
RoutineBuilder.build() silently swallows a real parse failure, emits
6 of 220 routines in a real test project come out with — an empty, invalid type — instead of their real type.
Root cause, precisely: in elements.py, RoutineBuilder.build():
For these 6 routines, that call throws:
— a length-prefixed field somewhere in the Kaitai struct is reading a value that isn't a real length, requesting well over a billion bytes from a 328-byte remainder. That's a genuine structural parse failure on these routines' own header records, not a downstream content issue — and it's currently caught and silently discarded rather than surfaced.
A note on what I didn't assume: my first instinct was that all 6 would be the same routine type (since 5 of them are), so I nearly "corrected" the empty Type to a guessed value. Checked before doing that, and one of the 6 is actually a different type entirely from the other 5 — so whatever's structurally different about these routines' header records isn't type-specific. Glad I checked rather than shipped that guess; mentioning it in case it's a useful data point for narrowing down the cause.
Possibly relevant: in the real L5X, the 5 same-typed routines all carry nearly identical EditedDate timestamps (within about 80ms of each other) — looks like a single batch save/edit operation. Might be that a specific edit action leaves the on-disk record in a shape RxGeneric doesn't expect yet.
Suggested improvement, regardless of the root cause being found: at minimum, don't silently swallow the exception — log it or surface it somehow, so a user knows a routine's type/content genuinely failed to parse rather than assuming an empty routine is just... empty.
Diagnosed with the help of Claude (Anthropic) while building a downstream tool against this library — flagging that in case it affects how you'd like to handle this report. Happy to answer questions or share the specific record bytes if that'd help track it down.