microsoftgraph / microsoftgraph/msgraph-sdk-java-core
Batch response: Improved error handling when "UserCollectionResponse" is returned but discrimiator is set to "User"
还没有人认领这个 Issue。
- 主要语言
- 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:
The image shows the structure of parseNode in com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse for a request that CAN be parsed:
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)
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 com.microsoft.graph.core.requests.ResponseBodyHandler#handleResponse 开始,跟踪 POST $batch 响应的嵌套 body 如何传递给解析节点。检查 BatchResponseContentCollection#getResponseById 和提供的嵌套 JSON 复现。完成标准是嵌套的 UserCollectionResponse 对象能够被正确解析,并且对于无法解析的响应能够适当地失败。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- java
- 领域
- api, backend
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100