parseChromeResponse results flattening flawed?

[davidcockbill]

I am having issues with the pass through flattening concept for the interface, where the caller kind of does not have to traverse the results tree in certain cases. There is a description of this in a comment in ChromeDevToolsSession.parseChromeResponse.

I have already had to put in a fix for empty results in #83.

But I have just hit another issue in parsing the json to produce CompileScriptResult returned by Runtime.compileScript. Here is an example result:

{
    "id": 15,
    "result": {
        "exceptionDetails": {
            "exceptionId": 1,
            "text": "Uncaught",
            "lineNumber": 46,
            "columnNumber": 4,
            "scriptId": "3",
            "exception": {
                "type": "object",
                "subtype": "error",
                "className": "SyntaxError",
                "description": "SyntaxError: Unexpected identifier 'r'",
                "objectId": "-7713972452990658375.3.1"
            }
        }
    },
    "sessionId": "3BA69E9C8F8AB05ACD4A262C5A574E4D"
}

The issue is that the CompileScriptResult has two optional fields: exceptionDetails and scriptId. The problem is that the same named scriptId field also exists nested within the exceptionDetails. The Jackson parsing appears to be interpreting the exceptionDetails as the result, I think due to the duplicated field name in the nested json and the fact that the pass through flattening functionality has kicked in due to there only being a single entry (because there is no scriptId at the result level in this case).

I think if the scriptId and exceptionDetails were defined in the other order, this may have worked (by luck).

This flattening behaviour is a bit confusing to me and I'm not sure that the small amount of extra code you have to type in order to get at a results is too onerous.

I usually use GSON rather than Jackson for json parsing; so it may be that there is a Jackson annotation or idiom to sort this kind of problem.

@pschoenfelder, have you any suggestions on fixing this?

My immediate thoughts are to remove this flattening behaviour, but I guess this is an interface change that would affect the calling code for existing users.

I also haven't looked at the Code Generation which presumably has some rules for changing the published result type for domain methods that only return one result argument?