...segment at the end of the input.
The triggering raw segment in the input is at line 36: "DTP":
```
...
L30 EB*C**42^45*MA**26*0~
L31 DTP*292*RD8*20170101-20171231~
L32 EB*B**30*MA**26*0~
L33 HSD***DA**30*0~
L34 HSD***DA**31*60~
L35 HSD*****26*1~
L36 DTP*435*RD8*20170101-20171231~
...
```
(added line number at beginning of each line so we can reference them)
The issue is with the schema, where inside `EB` seg group, we have, in this particular order,
the following child segments: `EB`, `DTP`, `LS`, `HSD`. You can see the `DTP` seg is declared
in front of `HSD`, but in the input it appears after. Now both `DTP` and `HSD` seg decl has
`min = 0`. When edi reader sees the 3 `HSD`, it thinks it's okay, since `DTP` seg is optional.
Then edi reader sees the `DTP`. Unfortunately this time it can't find a proper placement match
for it, thus it considers the `EB` seg group is done. Cascadingly, it considers the wrapping
`transaction_set_id` seg group as well as the `GS` and `ISA` are all done. Thus it moves on.
Then it sees `SE` and `IEA` both are optional, so seems like to it everything is done. EDI
reader now rewinds the seg processing stacking all the way to the #root. At this moment, essentially
we have a dangling raw segment `DTP` unprocessed and unaccounted for. EDI reader should've
gracefully failed, but it didn't. Due a bug, it will try to mark the current instance of #root
seg decl done, and move onto the next instance of #root decl. But again, `DTP` is still not matched
in the next instance of #root (the first segment in this schema should always be `ISA`), it will
move on to the next instance of #root, yet again and again and again - infinite dead-loop.
The fix is:
If we can't match a raw seg name to the current decl stack, and if the current decl stack is
nothing but the virtual #root decl, then we have a dangling unmated seg and return an failure
immediately.