Missing ConfigureAwait in PageIterator.IntrapageIterateAsync
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Start with PageIterator.IntrapageIterateAsync(CancellationToken), focusing on its _requestAdapter.SendAsync call and the reported ConfigureAwait behavior. Reproduce the deadlock scenario with concurrent iteration from a .NET Framework 4.8.1 host, then verify that iteration completes when the caller bridges async and synchronous code.
Written by the indexing model from the issue text.
Description
Describe the bug
I'm using Graph from an old 4.8.1 Framework project predating the async paradigm that has its own Multithreading backend. So i need to bridge the async/sync Barrier somehow and did that successfully with one exclusion. I have a seldom deadlock when iterating over graph results via calls to
await pageIterator.IterateAsync().ConfigureAwait(false);
and then at the some point bringing it back into my thread via .GetAwaiter().GetResult();.
Tried all known variants here to get that synchronized back. Wrapping calls in Task.Run writing my own SynchronizationContext (there shouldn't be one involved beforehand it is not a winforms application or something like that) etc. Nothing helped.
What worked for me in the end was adding a ConfigureAwait(false) in the PageIterator.IntrapageIterateAsync(CancellationToken) code when it calls _requestAdapter.SendAsync
and building the Graph.Core package myself.
Expected behavior
The PageIterator should not deadlock when used in certain contexts.
How to reproduce
Have a NET. Framework host application not written as "async all the way" try to concurrently retrieve data (like mailbox folder content from multiple mailboxes) that needs iterating and wait for a deadlock.
SDK Version
4.0.1
Latest version known to work for scenario above?
Don't use non async/await based code anymore. But i can't ;(
Known Workarounds
n/a
Debug output
n/a
Configuration
All currently supported Windows Desktop and Server Versions in x64 (presumably also x86 but have not tested)
Net. Framework 4.8.1
Presumably not specific to that configurations
Other information
No response
- Dominant language
- C#
- Stars
- 164
- Forks
- 65
- Avg merge
- 38m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoftgraph/msgraph-sdk-dotnet-core
-
status:waiting-for-triage type:bug
Difficulty 3/5 1-2 days Newbie friendliness 55/100
microsoftgraph/msgraph-sdk-dotnet-core#1047 · 3 comments · 8 reactions ·
-
status:waiting-for-triage
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
microsoftgraph/msgraph-sdk-dotnet-core#1046 · 2 comments · 2 reactions ·
-
.NET
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
microsoftgraph/msgraph-sdk-dotnet-core#1003 · 1 assignee ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
All issues in microsoftgraph/msgraph-sdk-dotnet-core
Similar issues
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
t/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
ci-failure-cause test-failure
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area:auth FE mvp P3
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
klasolsson81/jobbliggaren#1788 ·