TL;DR: if the Logz.io CloudWatch shipper mangles NodeJS Lambda logs, the parser assumed the 3-part Python format (timestamp, requestID, message) but NodeJS lines have 4 parts including the log level. Upgrade the shipper to a version containing the PR #42 fix; the maintainer confirmed AWS Lambda log formats differ per runtime.

## Steps

1. Upgrade the Logz.io CloudWatch logs shipper past PR #42.

   Expected: the parser handles the 4-part NodeJS format (timestamp, requestID, logLevel, message).

2. Send fresh NodeJS Lambda invocations and check Logz.io.

   Expected: log levels parse correctly and START/END/REPORT lines are ignored again. Success check: NodeJS logs look as clean as the Python ones.

## When to use this

- NodeJS Lambda logs arrive misparsed in Logz.io while Python function logs are fine.
- START/END/REPORT lines leak through instead of being filtered.

## When NOT to use this

- All runtimes misparse; check the shipper config instead.
- Logs never arrive at all; that is a delivery problem.

## Compatibility

- Logz.io CloudWatch logs shipper with the PR #42 fix; mixed-runtime (NodeJS + Python) setups.

## Variant phrasings

- "logzio lambda nodejs logs misparsed"
- "logz.io cloudwatch shipper log level missing"

## Root cause

AWS Lambda log formats differ per runtime, and the parser had only been tested against the Python 3-part format. On NodeJS functions the log level landed in the message slot and the real message shifted, while the START/END/REPORT filter missed.

## Edge cases

- The reporter-verified local workaround was changing the parse to 4 parts by hand, but upgrading is the real fix; do not fork the parser.