Fix ISSUE-141: edi reader stuck in a dead-loop with unrecognized raw segment at the end of the input. #143
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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.
Codecov Report
@@ Coverage Diff @@
## master #143 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 43 43
Lines 1977 1983 +6
=========================================
+ Hits 1977 1983 +6
Continue to review full report at Codecov.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #141:
The triggering raw segment in the input is at line 36: "DTP":
(added line number at beginning of each line so we can reference them)
The issue is with the schema, where inside
EBseg group, we have, in this particular order, the following child segments:EB,DTP,LS,HSD. You can see theDTPseg is declared in front ofHSD, but in the input it appears after. Now bothDTPandHSDseg decl hasmin = 0. When edi reader sees the 3HSD, it thinks it's okay, sinceDTPseg is optional. Then edi reader sees theDTP. Unfortunately this time it can't find a proper placement match for it, thus it considers theEBseg group is done. Cascadingly, it considers the wrappingtransaction_set_idseg group as well as theGSandISAare all done. Thus it moves on. Then it seesSEandIEAboth 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 segmentDTPunprocessed 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,DTPis still not matched in the next instance of #root (the first segment in this schema should always beISA), 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 a failure immediately.