Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hi, I think it's needed to wrap semaphore usage into finally block in order to avoid deadlock #7778

Open
victor-makovsky-covergo opened this issue Nov 28, 2024 · 1 comment

Comments

@victor-makovsky-covergo

Product

Hot Chocolate

Version

12.0.0

Link to minimal reproduction

https://github.com/ChilliCream/graphql-platform/blob/c477e13e161fe6ff682a6849facad19c63d9f83d/src/HotChocolate/Core/src/Execution/Configuration/DefaultRequestExecutorOptionsMonitor.cs#L82C13-L82C34

Steps to reproduce

May be this is very edge case but sometimes it reproduces on my project and leads to deadlock (graphql requests start but never finish and hanging waiting for sempaphore).
Image

What is expected?

Semaphore is always released, release statement is put into finalize statement.

What is actually happening?

Deadlock

Relevant log output

Additional context

No response

@victor-makovsky-covergo
Copy link
Author

victor-makovsky-covergo commented Nov 29, 2024

It is possible to reproduce exception and deadlock when application just started and then first graphql request is sent and then cancelled (browser cancelled request), this leads to semaphore in the options monitor being always at 0 counter which prevents all graphql requests from processing and requires application restart to fix.
Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant