Support the nested blocks of MT021, MT056 and MT096 in the parser - #347
Open
ptorres-prowide wants to merge 5 commits into
Open
ptorres-prowide wants to merge 5 commits into
ptorres-prowide wants to merge 5 commits into
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
ptorres-prowide
force-pushed
the
CU-18ubww2_Enhance-MT-parser-to-support-nested-blocks
branch
2 times, most recently
from
August 26, 2026 21:27
6103236 to
5557b27
Compare
The block 4 of these system messages carries nested blocks, which the tag list block parser was splitting at the first closing brace. As a result the nested block 3 and block 5 lost their closing brace, their sub-tags leaked as siblings of the block 4 (colliding with the MT021 field 108) and the MT056 field 270 was truncated, so the message could not be written back as valid FIN. The tag value is now read balancing the curly braces, but only for the tag names where SWIFT defines nested blocks: the block identifiers 1 to 5 and the field 270. Every other tag keeps the historical reading, which matters for malformed content such as a service message error code left unclosed before the next field. Verified with no difference over the 8833 FIN samples of the integrator corpus. Also, parseBlock3 and parseBlock5 now accept the block content without the block identifier, which is the form returned by the nested block tag values, so the nested message can be rebuilt out of them.
ptorres-prowide
force-pushed
the
CU-18ubww2_Enhance-MT-parser-to-support-nested-blocks
branch
from
September 11, 2026 19:01
5557b27 to
1d7b0ca
Compare
The block 4 of these system messages carries nested blocks, which the tag list block parser was splitting at the first closing brace. As a result the nested block 3 and block 5 lost their closing brace, their sub-tags leaked as siblings of the block 4 (colliding with the MT021 field 108) and the MT056 field 270 was truncated, so the message could not be written back as valid FIN. The tag value is now read balancing the curly braces, but only for the tag names where SWIFT defines nested blocks: the block identifiers 1 to 5 and the field 270. Every other tag keeps the historical reading, which matters for malformed content such as a service message error code left unclosed before the next field. Verified with no difference over the 8833 FIN samples of the integrator corpus. Also, parseBlock3 and parseBlock5 now accept the block content without the block identifier, which is the form returned by the nested block tag values, so the nested message can be rebuilt out of them.
zubri
force-pushed
the
CU-18ubww2_Enhance-MT-parser-to-support-nested-blocks
branch
from
September 11, 2026 23:37
1d7b0ca to
c58e39f
Compare
https://github.com/prowide/prowide-core into CU-18ubww2_Enhance-MT-parser-to-support-nested-blocks
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The block 4 of these system messages carries nested blocks, which the tag list block parser was splitting at the first closing brace. As a result the nested block 3 and block 5 lost their closing brace, their sub-tags leaked as siblings of the block 4 (colliding with the MT021 field 108) and the MT056 field 270 was truncated, so the message could not be written back as valid FIN.
The tag value is now read balancing the curly braces, but only for the tag names where SWIFT defines nested blocks: the block identifiers 1 to 5 and the field
270. Every other tag keeps the historical reading, which matters for malformed content such as a service message error code left unclosed before the next field. Verified with no difference over the 8833 FIN samples of the integrator corpus.
Also, parseBlock3 and parseBlock5 now accept the block content without the block identifier, which is the form returned by the nested block tag values, so the nested message can be rebuilt out of them.