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
-
Flight SQL JDBC parses boolean properties case-sensitively, silently disabling TLS for useEncryption=TRUE可能已有人在做 @Arawoof06 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 79/100
apache/arrow-java#1357 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 77/100
apache/rocketmq-dashboard#6610 ·
維護者通常 3 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
MetricsHub/metricshub-community#1396 ·
維護者通常 1 天內回覆
-
L: java:gradle L: java:maven L: ruby:bundler T: bug 🐞
難度 2/5 1-3 小時 新手友好度 76/100
dependabot/dependabot-core#16547 ·
維護者通常 1 天內回覆
-
Citationcount column sorts alphabetically instead of numerically可能已有人在做 @kpunia306 今天認領。 未關閉status: needs-triage
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆