parseChromeResponse results flattening flawed?

Start by reading ChromeDevToolsSession.parseChromeResponse and the CompileScriptResult definition, then trace the code-generation rules for methods with one result argument. Use the provided Runtime.compileScript response to reproduce how the nested scriptId is interpreted. Done means the response is parsed without confusing nested and top-level fields, with the impact on existing flattening callers understood.

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?