Open chemelli74 opened 1 month ago
Thank you for opening this issue as well as your patience!
Let me try to summarize my current understanding based upon the history referenced and my own investigation into the botocore loaders module. I also have a few clarifying questions for you.
I understand that there is a warning by Home Assistant about blocking calls in its aws
component. The warning appears to be correct in the sense that botocore, and by extension aiobotocore, uses file I/O to lazy load the data models needed to do its job.
What practical issues arise besides the warning in home assistant. Are there any negative effects?
If there are even any actual issues, mitigations or fixes may potentially be applied at Home Assistant, botocore and/or aiobotocore.
@thehesiod has provided suggestions on pre-warming the model cache that could be implemented by Home Assistant.
Has this been attempted? What other steps has Home Assistant taken to mitigate negative effects, if any? Does Home Assistant use long-living sessions or are they frequently recreated?
As @thehesiod stated, issues arising from botocore loaders are caused by their design, i.e. their reliance on file I/O and a large number of JSON files to be processed. The botocore teams seems to be aware of the situation, attempted optimisations in the past, but have not shared any plans on further redesigning that aspect of botocore. We can assume that botocore loaders will stay as they are for the foreseeable future.
We already touched upon a few things that could be done by aiobotocore, including:
Async loaders The purpose of aiobotocore is to allow for async calls to AWS services. We currently do not provide async implementations of botocore's loaders. This might be feasible and I have started to work in that direction. If successful, that would provide a path to non-blocking loaders. However, I do not want the raise any expectations and cannot make any promises yet.
Surgical patches There are also more surgical patches that might work around particular blocking codepaths, such as the proposals in #1120 and #1196. As you have noted, @thehesiod is sceptical about resorting to threads / the default executor, and I have voiced concern with regards to drift they introduce and the added complexity we need to deal with going forward. Also, these patches likely conflict with 1. while not fixing blocking file I/O in the vast majority of cases (paginators, waiters, ...). I would like to exhaust other options, before considering this path.
I hope this is a fair summary of the discussion so far and look forward to your responses.
Describe the bug Home Assitant recently added the ability to detect I/O function that block event loop:
After trying a first fix in #1120, I was redirected to botocore. I opened a issue there: https://github.com/boto/botocore/issues/3222, but was closed as botocore doesn't use event loop at all. After some more discussions in the original PR, a new idea was raised and I applied it to a new fix in #1196. Lately I was asked to open a issue to discuss the approach.
Checklist
pip check
passes without errorspip freeze
resultspip freeze results pip_freeze.txt
Environment:
Additional context Add any other context about the problem here.