I could be mistaken, but from a distance this fix seems a bit brittle. Are we certain that performing engine.extractAuthor on an entry that doesn't actually have an author will always return undefined? Aren't we chancing it a bit? Are we certain that the underlying encoded data can't yield a false-positive? What if one day the extractAuthor implementation changes?

Again, I'm not familiar with the implementation of extractAuthor. However, I think that it would be best to be more assertive and to first find out which one is the correct entry from where to extract the author, and only then get the author using the extractAuthor method.

It's just a thought. Please take it with a pinch of salt, because I really am not familiar with this logic in PJS. 🙂

Great question! Your concern about relying on undefined returns is valid. However, the current approach is safe because extractAuthor() validates the engine identifier first, before interpreting any payload data:

Example: When we call extractAuthor() on a CMLS preRuntime log:

• Engine = 'CMLS' (4 bytes: 0x434d4c53)
• Doesn't match 'aura', 'BABE', 'pow_' ...
• Returns undefined without decoding the payload
• Loop continues to the next preRuntime log

This means the engine ID acts as a gatekeeper -- random bytes in unrecognized engine payloads can't produce false positives because the engine string is checked before any data interpretation.

I agree with the reasoning here. 👍