Created by: bhaan
fixes #102 (closed)
problem
While "walking" over every field during message validation, each field is passed to validateVisitField to check and validate repeating groups if the current field happens to be the start of a repeating group. After checking the current field, it pops that field off the stack of remaining fields in the message.
When validating a repeating group, the starting field is passed to validateVisitGroupField which iterates over the remaining fields in the message, popping each field off the stack as it goes along.
Therefore, when the repeating group validation returns, validateVisitField will pop the current field off the stack of remaining fields, which is actually the next field in the message after the repeating group.
In the case of the MarketDataRequest message described in issue #102 (closed), there are two repeating groups placed back-to-back. The first being NoRelatedSym (tag 146), the second being NoMDEntryTypes (tag 267). So after validating the repeating group for tag 146, the next tag (267) is accidentally popped off the remaining field stack. This leaves the rest of the fields within the NoMDEntryTypes group on the field stack, and are then validated against the message definition for MarketDataRequest which doesn't contain the field type MDEntryType (tag 269). Resulting in the error: "Tag not defined for this message type"
solution
Simple. Don't pop the current field off the remaining field stack if it's the start of a repeating group, because validateVisitGroupField will do it for us.
tests
Coincidentally, the tests for validateVisitGroupField contained the scenarios needed to verify this behavior. Because the functions for validateVisitField and validateVisitGroupField have the same interface, and the former invokes the latter, I simply consolidated the two to call validateVisitField.