Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Java] Permit decoders to be built that do not validate empty tags #534

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

writeoncereadmany
Copy link

We have seen numerous cases where venues are sending us invalid FIX of the form 35=0|12345=|10-123

ie, where a tag is defined with no value / an empty string.

This does not conform to the FIX standard, so it's technically correct to reject the message as malformed, however: if a venue's sending us that and is refusing to fix it (or is incapable of doing so), we'd rather not fail validation and instead just treat it as empty.

This change allows a build-time flag on generated decoders to ignore empty tags instead of rejecting them.

@@ -129,6 +131,21 @@ public CodecConfiguration wrapEmptyBuffer(final boolean wrapEmptyBuffer)
return this;
}

/**
* Suppresses checks for empty tags, eg |1234=|
* instead of rejecting when tag is empty, treat the tag as absent
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, because you're still parsing those fields, the hasFoo() methods will return true. I think that's dangerous, because you won't be able to tell a difference between, for example, |43=N| and |43=|.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, damn, good point. I'll revise to make sure we don't parse the tags either and properly treat them as absent.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now updated the change to not parse the tags, and added tests to assert those fields are absent (rather than present but empty/default).

I've included both String and non-String field tests too (to show it gracefully handles both parsed and non-parsed fields).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants