Sometimes missing single or multiple Contacts when fetching a Folder of Contacts
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start from the reporter's snippet, which pages through contacts() with top=100 and a PageIterator whose processPageItemCallback adds each contact to a list, then compares that list with the contacts().count() value. Reproducing the bug needs a user whose contact folder misses items, so the first step is to log which contact IDs are returned on each page and find where the gap appears. Done means a reproducible case that explains the dropped contacts, or a clear finding about the paging or serialization path in the SDK.
由索引模型根据 Issue 内容生成。
描述
I have written a Module, that should import the Exchange Contacts from Office365 directly in the PBX's addressbook.
This has been working for a long time.
But from time to time i get a report about a missing contact, that exists in the Office365 Contact folder.
What i do exactly:
I use the MS Graph to fetch the Contacts, and dump them into a .csv file, before importing it into the pbx.
Those missing contacts don't show in the .CSV dump, which means that the contacts wasn't fetched or wasn't written due to some odd reason.
But if i check the Office365, the contact is there.
- If i trigger the script to fetch all contacts again, the contact still doesn't show up in my csv
- If i copy the original, missing contact, and trigger the script, the copy shows up in the .csv if i delete the copy the original still won't show up in the .csv if i trigger it again.
- If i update the existing contact by for example adding "Test" to their name, and save, and trigger the script, the contact shows up in the .csv
I use the following code to fetch the contacts:
O365Provider O365P = new O365Provider(TenantID, ClientID, ClientSecret, Scopes, log); //Wrapper for the GraphServiceClient with my custom logger
GraphServiceClient GSC = O365P.getGSC();
User U = GSC.users().byUserId(UserIDorUPN).get();
Integer Amount = GSC.users().byUserId(U.getId()).contacts().count().get();
log.debug("Amount in Folder: " + Amount);
List<Contact> Contacts = new ArrayList<Contact>();
ContactCollectionResponse Request= GSC.users().byUserId(U.getId()).contacts().get(requestConfiguration -> {
requestConfiguration.queryParameters.top = 100; //Pagination of 100
});
// This Code is based on the MS example: https://learn.microsoft.com/en-us/graph/sdks/paging?tabs=java
PageIterator<Contact, ContactCollectionResponse> pageIterator = new PageIterator.Builder<Contact, ContactCollectionResponse>()
.client(GSC)
.collectionPage(Request)
.collectionPageFactory(ContactCollectionResponse::createFromDiscriminatorValue)
.requestConfigurator( requestInfo -> {
requestInfo.addQueryParameter("%24top", 100);
return requestInfo;
})
.processPageItemCallback( contact -> {
Contacts.add(contact);
return true;
}).build();
pageIterator.iterate();
log.debug("Fetched: " + Contacts.size() +" Contacts");
Now the thing is, most of the time these contacts aren't new, most of them have been existing for a while in the office365 contacts, or even have been migrated there from old exchange servers. In one case i had a newly created contact show the exact issue for a customer.
I cannot pinpoint the source of this issue.
I might have tought the pagination might be wrong, but i created a Test folder with 2'133 Contacts, and all of them have been dumped to the .csv successfully using this code.
[2026-10-09T13:43:57,859] [DEBUG] [] [] [O365 Connector MSGraph] Scopes: [https://graph.microsoft.com/.default]
[2026-10-09T13:43:57,859] [DEBUG] [] [] [O365 Connector MSGraph] Setting Up Provider...
[2026-10-09T13:43:57,859] [DEBUG] [] [] [O365 Connector MSGraph] Looking for: [[email protected]]
[2026-10-09T13:43:58,098] [DEBUG] [] [] [O365 Connector MSGraph] [[email protected]] found!
[2026-10-09T13:43:58,189] [DEBUG] [] [] [O365 Connector MSGraph] Amount in Folder: 2133
[2026-10-09T13:43:59,791] [DEBUG] [] [] [O365 Connector MSGraph] Fetched: 2133 Contacts
[2026-10-09T13:43:59,838] [DEBUG] [] [] [O365 Connector MSGraph] Writing: 2133 Contacts to File: [/path/to/csv.csv]
[2026-10-09T13:43:59,838] [DEBUG] [] [] [O365 Connector MSGraph] Writing Header
[2026-10-09T13:43:59,858] [DEBUG] [] [] [O365 Connector MSGraph] Done Writing
I'm at a loss how to go about this, and can't find anything useful about this isuse.
Any ideas how to go about this?
//edit: I think it's actually close or the same issue as this: https://stackoverflow.com/questions/70374893/loading-all-contacts-using-the-microsoft-graph-api-sometimes-looses-skips-pages
Sincerely
Fabian95qw
- 主要语言
- Java
- 星标
- 446
- 派生
- 154
- 平均合并
- 10 小时 54 分钟
- 30 天内合并 PR
- 5
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoftgraph/msgraph-sdk-java 的其他 Issue
-
status:waiting-for-triage type:bug
难度 2/5 1-3 小时 新手友好度 68/100
microsoftgraph/msgraph-sdk-java#2610 ·
维护者通常 1 天内回复
-
status:waiting-for-triage type:bug
难度 3/5 1-2 天 新手友好度 55/100
microsoftgraph/msgraph-sdk-java#2656 ·
维护者通常 1 天内回复
-
status:waiting-for-triage type:bug
难度 4/5 3-5 天 新手友好度 38/100
microsoftgraph/msgraph-sdk-java#2654 ·
维护者通常 1 天内回复
-
status:waiting-for-triage
难度 4/5 3-5 天 新手友好度 35/100
microsoftgraph/msgraph-sdk-java#2639 ·
维护者通常 1 天内回复
-
status:waiting-for-triage type:bug
难度 3/5 1-2 天 新手友好度 35/100
microsoftgraph/msgraph-sdk-java#2589 · 1 条评论 ·
维护者通常 1 天内回复
查看 microsoftgraph/msgraph-sdk-java 的全部 Issue
相似的 Issue
-
:ml/Transform >bug Team:ML
难度 2/5 半天 新手友好度 64/100
elastic/elasticsearch#161960 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 4 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
objectionary/lints#1556 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
wildfly/wildfly-launcher#99 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
apache/rocketmq#11427 · 2 条评论 ·
维护者通常 1 天内回复