Deserialize error "Invalid type marker byte"

[georgewfraser]

Smile which is correctly decoded by smile-tool throws JsonParseException when deserialized with smile 2.7.1. The input smile corresponds to the JSON:

[{ "(VLAN) Days of the week is member available for this work?": null }
]

It seems to depend very precisely on the field name.

Reproduce by cloning https://github.com/fivetran/smile-error and running mvn test.

Possibly related to #31 and #27

[georgewfraser]

Occurs with:

• jackson-core 2.60
• jackson-databind 2.6.0
• jackson-dataformat-smile 2.6.0

Does not occur with:

• jackson-core 2.60
• jackson-databind 2.6.0
• jackson-dataformat-smile 2.5.5

[georgewfraser]

I managed to create a test case that reproduces this error within jackson-dataformat-smile:

https://github.com/fivetran/jackson-dataformat-smile/tree/issue-34

[georgewfraser]

My understanding of the Jackson codebase is minimal but I think I this may be a fix:

fivetran@b6670d9

I think I signed a CLA for a Jackson project at some point.

[cowtowncoder]

Thank you for the report & test case! I'll try to get this fixed ASAP; I assume your fix is valid, but just want to add test first etc. Will get nicely in 2.7.2.

[cowtowncoder]

Hmmh. Very interesting -- I have hard time reproducing this using anything other than binding into JsonNode. Still not quite sure why that makes a difference; it's not (as I first thought) due to use of nextFieldName() call, but something else. But at least it can be reproduced.

Actual field name does not matter, except that it has to be at least 57 chars/bytes, to trigger the code path.

[cowtowncoder]

57 char limit makes sort of sense, although exposes a minor flaw in encoder (for ASCII-only name, should allow short form for up to 64 chars). But aside that, it's then different code path that causes the problem in 2.6/2.7.

And actually code path is in deed nextFieldName(), it just triggers the problem bit differently.