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

XContentParser Behaves Differently for Stream and Byte Array #61489

Open
original-brownbear opened this issue Aug 24, 2020 · 5 comments
Open
Labels
>bug :Core/Infra/Core Core issues without another label help wanted adoptme Team:Core/Infra Meta label for core/infra team

Comments

@original-brownbear
Copy link
Member

Optimizing BytesReference parsing in #61447 revealed a subtle bug in x-content parsing.

The following test:

    public void testIncompatibleStreamTypes() throws Exception {
        final Map<String, Object> map = Map.of("foo", "bar");
        final BytesReference jsonBytes = BytesReference.bytes(JsonXContent.contentBuilder().map(map));
        final Map<String, Object> deserialized = SmileXContent.smileXContent.createParser(
                NamedXContentRegistry.EMPTY, DeprecationHandler.IGNORE_DEPRECATIONS, jsonBytes.streamInput()).map();
        assertEquals(deserialized, Collections.emptyMap());

        final BytesRef bytes = jsonBytes.toBytesRef();
        final Map<String, Object> deserialized2 = SmileXContent.smileXContent.createParser(
                NamedXContentRegistry.EMPTY, DeprecationHandler.IGNORE_DEPRECATIONS, bytes.bytes, bytes.offset, bytes.length).map(); // this throws
    }

will actually pass until the last line which will throw:

com.fasterxml.jackson.core.JsonParseException: Input does not start with Smile format header (first byte = 0x7b) -- rather, it starts with '{' (plain JSON input?) -- can not parse
 at [Source: (byte[])"{"foo":"bar"}"; line: -1, column: 0]

So for reading from streams, we simply read empty map when the type is off but when reading from a byte array we (in my opinion correctly) throw an exception. I think we should throw that same exception when reading from a stream of the wrong content type shouldn't we?

@original-brownbear original-brownbear added >bug :Core/Infra/Core Core issues without another label needs:triage Requires assignment of a team area label labels Aug 24, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (:Core/Infra/Core)

@elasticmachine elasticmachine added the Team:Core/Infra Meta label for core/infra team label Aug 24, 2020
@original-brownbear
Copy link
Member Author

Relates #61485 which was caused by this subtle difference where it resulted in some pointless test.

@rjernst
Copy link
Member

rjernst commented Aug 24, 2020

+1 to a consistent error

@jaymode jaymode removed the needs:triage Requires assignment of a team area label label Aug 25, 2020
@rjernst rjernst added the needs:triage Requires assignment of a team area label label Dec 3, 2020
@rjernst
Copy link
Member

rjernst commented Dec 18, 2020

I'm adding the help wanted since this is still an issue, and should be relatively easy to fix, but has not been a priority since it is a minor inconsistency.

@rjernst rjernst added help wanted adoptme and removed needs:triage Requires assignment of a team area label labels Dec 18, 2020
@Kiriakos1998
Copy link
Contributor

Hello @rjernst @jaymode @original-brownbear , can I work on this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Core/Infra/Core Core issues without another label help wanted adoptme Team:Core/Infra Meta label for core/infra team
Projects
None yet
Development

No branches or pull requests

5 participants