[5.0.x] Fix panic when calling certain API endpoints #552
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
antiochp
approved these changes
Dec 17, 2020
quentinlesceller
pushed a commit
to quentinlesceller/grin-wallet
that referenced
this pull request
Mar 5, 2021
* Detect if already in runtime context * Add comment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The HTTP client is currently used both outside and inside of a tokio runtime context. In the latter case we are not allowed to do a blocking call to our global runtime, which unfortunately means we have to spawn a new thread.
At the moment we are mixing asynchronous and synchronous contexts all over the place, which is not great. This means that we are blocking inside API calls, reducing the amount of concurrent request we could serve. In practice, this probably is not noticeable since the number of requests to a wallet API is usually not that huge. Additionally a lot of wallet operations require a write lock on the db, which means requests have to be handled in-part sequentially anyway.
Ideally, we'd move to fully asynchronous, but this would require a relatively large refactor of the wallet. Another thing we could look into is if we can wrap each api call in a
spawn_blocking, although i suspect that is not really possible since we are using Hyper.Thanks to @bladedoyle for reporting the issue.