microsoftgraph / microsoftgraph/msgraph-sdk-java-core

Batch response: Improved error handling when "UserCollectionResponse" is returned but discrimiator is set to "User"

オープン
#1,587 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

enhancement
主要言語
Java
スター
67
フォーク
34
PR マージ指標
30日以内にマージされた PR はありません

説明

Graph Core Version: 3.1.9
Kiota Version: 1.1.7
Affected Method: com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse

Edit: Added a comment explaining the reason of this behavior and changed the issue title.

Microsoft Graph core returns an object with all properties set to null, if the response body contains a nested structure.

Expected behavior

com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse should parse nested response objects. And maybe throw an error if a response can not be parsed.

Actual behavior

com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse returns a object with all properties set to null.

Steps to reproduce the behavior

Execute the following request using the Graph API: POST https://graph.microsoft.com/v1.0/$batch

Body is GET users?$filter=identities/any(c:c/issuerAssignedId eq '<the issuer Assigned id>' and c/issuer eq 'contoso.com')&$select=id,displayName,email,UserPrincipalName,identities,accountEnabled

{
    "requests": [
        {
            "id": "d26195f1-aa54-461f-9119-aa98687ea27e",
            "url": "/users?%24filter=identities%2Fany% ... ",
            "method": "GET",
            "headers": {
                "accept": "application/json"
            }
        }
    ]
}

Response: shortended just to show the structure. Note the nested structure in the body which causes the erroneous behavior.

{
    "responses": [ 
         {
            "id": "766378b9-df71-473d-909a-da07fa9f10c5",
            "status": 200,
            "headers": {...},
            "body": {
                "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(id,displayName,email,userPrincipalName,identities,accountEnabled)",
                "value": [
                    {
                        "id": "<some Id>",
                        "displayName": "John Doe",
                        "userPrincipalName": "cpim_something",
                        "accountEnabled": false,
                        "identities": [...]
                    }
                ]
            }
        }
    ]
}

The image shows the structure of parseNode in com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse for a Request that CAN NOT be parsed:
image

The image shows the structure of parseNode in com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse for a request that CAN be parsed:
image

Remarks

I verified this by unnesting the structure and re-parsing the response:

ByteArrayInputStream unnestedResponse =  new ByteArrayInputStream(((java.util.ArrayList)((JsonArray)((com.google.gson.internal.LinkedTreeMap.Node)((com.google.gson.internal.LinkedTreeMap)((JsonObject)((JsonParseNode)parseNode).currentNode).members).entrySet().toArray()[1]).getValue()).elements).get(0).toString().getBytes());

String contentType = body.contentType().type() + "/" + body.contentType().subtype();

this.parseNodeFactory
    .getParseNode(contentType, unnestedResponse)
    .getObjectValue(this.factory);

An intermediate fix (not yet tested) could be to provide your own implementation of ResponseBodyHandler when invoking com.microsoft.graph.core.content.BatchResponseContentCollection#getResponseById(java.lang.String, com.microsoft.kiota.ResponseHandler)

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse から開始し、POST $batch レスポンスのネストされた body が parse node に渡される方法を追跡します。BatchResponseContentCollection#getResponseById と、提供されているネストされた JSON の再現例を確認します。ネストされた UserCollectionResponse オブジェクトが正しくパースされ、パースできないレスポンスに対して適切に失敗すれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
api, backend
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。