xml-stream | Made for Node | Parser library

tl;dr In tag' "row" parseAttributes parseContent, the check function belongs to parseAttributes, not to parseContent.

xml-conduit is (notably) designed around the following invariants:

1. when parsers are of type ConduitT Event o m (Maybe a), the Maybe layer encodes whether Events have been consumed
2. tag' parseName parseAttributes parseContent consumes Events if and only if both parseName and parseAttributes succeed
3. tag' parseName parseAttributes parseContent runs parseContent if and only if both parseName and parseAttributes succeed

In parseDoc:

• the check function is called in the parseContent part; at this stage, tag' is already committed to consume Events, as per invariant 2
• a stack of 2 Maybe layers are joined together:
  • the output of the check function, which encodes whether the current element is relevant
  • the "standard" Maybe layer from tag' signature, which encodes whether Events have been consumed, as per invariant 1

This essentially breaks invariant 1: when check returns Nothing, parseDoc returns Nothing despite consuming Events of the whole element. This results in undefined behavior of all combinators of xml-conduit, notably many' (analyzed below.)

The many' combinator relies on invariant 1 to do its job. It is defined as many' consumer = manyIgnore consumer ignoreAnyTreeContent, that is:

1. try consumer
2. if consumer returns Nothing, then skip element or content using ignoreAnyTreeContent, assuming it hasn't been consumed yet by consumer, and recurse back to step (1)

In your case, consumer returns Nothing for the Daily Update 10.20.2020 item, even though the complete element has been consumed. Therefore, ignoreAnyTreeContent is run as a means to skip that particular , but actually ends up skipping the next one instead (Weekly Report 10.14.2020).

Move the check logic to the parseAttributes part, so that Event consumption becomes coupled to whether check passes.