{"action":"created","issue":{"url":"https://api.github.com/repos/FasterXML/jackson-databind/issues/2152","repository_url":"https://api.github.com/repos/FasterXML/jackson-databind","labels_url":"https://api.github.com/repos/FasterXML/jackson-databind/issues/2152/labels{/name}","comments_url":"https://api.github.com/repos/FasterXML/jackson-databind/issues/2152/comments","events_url":"https://api.github.com/repos/FasterXML/jackson-databind/issues/2152/events","html_url":"https://github.com/FasterXML/jackson-databind/issues/2152","id":367573274,"node_id":"MDU6SXNzdWUzNjc1NzMyNzQ=","number":2152,"title":"Sporadic failures on deserialization of cyclic object graph","user":{"login":"nlisker","id":37422899,"node_id":"MDQ6VXNlcjM3NDIyODk5","avatar_url":"https://avatars0.githubusercontent.com/u/37422899?v=4","gravatar_id":"","url":"https://api.github.com/users/nlisker","html_url":"https://github.com/nlisker","followers_url":"https://api.github.com/users/nlisker/followers","following_url":"https://api.github.com/users/nlisker/following{/other_user}","gists_url":"https://api.github.com/users/nlisker/gists{/gist_id}","starred_url":"https://api.github.com/users/nlisker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nlisker/subscriptions","organizations_url":"https://api.github.com/users/nlisker/orgs","repos_url":"https://api.github.com/users/nlisker/repos","events_url":"https://api.github.com/users/nlisker/events{/privacy}","received_events_url":"https://api.github.com/users/nlisker/received_events","type":"User","site_admin":false},"labels":[{"id":362288980,"node_id":"MDU6TGFiZWwzNjIyODg5ODA=","url":"https://api.github.com/repos/FasterXML/jackson-databind/labels/2.9","name":"2.9","color":"0e8a16","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-10-07T17:04:08Z","updated_at":"2018-11-05T16:51:55Z","closed_at":null,"author_association":"NONE","body":"When deserializing a cyclic object graph, sometimes an exception will be thrown\r\n\r\n> com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot resolve ObjectId forward reference using property 'propertyName' (of type someType): Bean not yet resolved\r\n\r\nIv'e prepared a reproduction example: https://github.com/nlisker/JacksonRepoExample\r\n\r\nThe project contains:\r\n\r\n* 2 (interface) types, `LandPlot` and `Structure`, which hold references to each other. Implementation1 of these interfaces is serialized and then deserialized into implementation2. The `BuildPlan` POJOs hold the data that is serialized and deserialized into.\r\n* `StateGenerator` creates an example `BuildPlan` for serialization. \r\n* `SerializationTools` contains the methods for serializing and deserializing.\r\n* `SerializationToolsTest` is a JUnit test that creates a `BuildPlan` and then tries to serialize and deserialize it with the classes above.\r\n* [JSOG](https://github.com/jsog/jsog-jackson) ID generator dependency. I don't think this is where the problem is coming from, but I could be wrong.\r\n\r\nAfter setting up the project, execute `serializeCycle` several times (you might need 20). Sometimes it will work, sometimes it will throw:\r\n\r\n> com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot resolve ObjectId forward reference using property 'landPlot' (of type impls2.StructureImpl2): Bean not yet resolved\r\n\r\nwith a very long stack trace.\r\n\r\nThe method `testSerializeCycle` runs `serializeCycle` in a loop, but you will notice that either all attempts fail or all succeed. This tells me that the thing that causes the difference is not in the process of creating a POJO, serializing it, and then deserializing it. Instead, that difference happens each time the JVM is started. I suspect that there is a dependence on the order of values returned from a map, which is randomized on each JVM startup since Java 9. The order of the values in the JSON is different, and sometimes it will fail and sometimes not depending on this order."},"comment":{"url":"https://api.github.com/repos/FasterXML/jackson-databind/issues/comments/435948281","html_url":"https://github.com/FasterXML/jackson-databind/issues/2152#issuecomment-435948281","issue_url":"https://api.github.com/repos/FasterXML/jackson-databind/issues/2152","id":435948281,"node_id":"MDEyOklzc3VlQ29tbWVudDQzNTk0ODI4MQ==","user":{"login":"stickfigure","id":162508,"node_id":"MDQ6VXNlcjE2MjUwOA==","avatar_url":"https://avatars0.githubusercontent.com/u/162508?v=4","gravatar_id":"","url":"https://api.github.com/users/stickfigure","html_url":"https://github.com/stickfigure","followers_url":"https://api.github.com/users/stickfigure/followers","following_url":"https://api.github.com/users/stickfigure/following{/other_user}","gists_url":"https://api.github.com/users/stickfigure/gists{/gist_id}","starred_url":"https://api.github.com/users/stickfigure/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stickfigure/subscriptions","organizations_url":"https://api.github.com/users/stickfigure/orgs","repos_url":"https://api.github.com/users/stickfigure/repos","events_url":"https://api.github.com/users/stickfigure/events{/privacy}","received_events_url":"https://api.github.com/users/stickfigure/received_events","type":"User","site_admin":false},"created_at":"2018-11-05T16:51:55Z","updated_at":"2018-11-05T16:51:55Z","author_association":"CONTRIBUTOR","body":"It's hard to imagine this has anything to do with the JSOG code since there's almost no code there; it just makes a slight tweak to the serialization/deserialization of references. Jackson is doing all the work. I would be shocked if this same behavior didn't happen with regular scalar ids.\r\n\r\n`Cannot resolve ObjectId forward reference` sounds like a ref is being processed before an id. Tatu, I presume Jackson runs depth-first and expects ids before refs? Is everything being stored in LinkedHashMap?\r\n\r\nIt's got to be one of two cases:\r\n\r\n 1. The ids/refs are being written out of order. This should be easy to check - when there is a failure, look at the serialized form. If it looks right then the problem is #2.\r\n 2. On deserialization, the values are getting read into a structure that doesn't preserve order (ie HashMap).\r\n\r\nI don't really understand what goes on under the covers in Jackson, unfortunately. But given the behavior we're seeing, #2 seems more likely."}}
{"actor":{"display_login":"stickfigure"}}