Closed Houkime closed 2 years ago
Extra info: aiohttp 3.7.3 (added to the top also) aiohttp-apispec 2.2.1
self.plugin
here is a MarshmallowPlugin
, provided by apispec
python package (version 4.0.0).
__it is separate from aiohttp_apispec
__converter
here is an OpenAPIConverter
, provided by the same package. def schema2parameters(
self, schema, *, location, name="body", required=False, description=None
):
"""Return an array of OpenAPI parameters given a given marshmallow
:class:`Schema <marshmallow.Schema>`. If `location` is "body", then return an array
of a single parameter; else return an array of a parameter for each included field in
the :class:`Schema <marshmallow.Schema>`.
In OpenAPI 3, only "query", "header", "path" or "cookie" are allowed for the location
of parameters. "requestBody" is used when fields are in the body.
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#parameterObject
"""
location = __location_map__.get(location, location)
# OAS 2 body parameter
if location == "body":
param = {
"in": location,
"required": required,
"name": name,
"schema": self.resolve_nested_schema(schema),
}
if description:
param["description"] = description
return [param]
assert not getattr(
schema, "many", False
), "Schemas with many=True are only supported for 'json' location (aka 'in: body')"
fields = get_fields(schema, exclude_dump_only=True)
return [
self._field2parameter(
field_obj, name=field_obj.data_key or field_name, location=location,
)
for field_name, field_obj in fields.items()
]
While the code calling for it in aiohttp_apispec.py
looks like this.
if "responses" in data:
responses = {}
for code, actual_params in data["responses"].items():
if "schema" in actual_params:
raw_parameters = self.plugin.converter.schema2parameters(
actual_params["schema"],
required=actual_params.get("required", False),
)[0]
updated_params = {
k: v
for k, v in raw_parameters.items()
if k in VALID_RESPONSE_FIELDS
}
updated_params['schema'] = actual_params["schema"]
for extra_info in ("description", "headers", "examples"):
if extra_info in actual_params:
updated_params[extra_info] = actual_params[extra_info]
responses[code] = updated_params
else:
responses[code] = actual_params
data["responses"] = responses
So, it looks like a version incompatibility between the aiohttp_apispec
and apispec
, which most probably has occured when apispec
turned 4.0.0
.
this incompatibility was introduced by https://github.com/marshmallow-code/apispec/commit/ee8002b466aeebb753bdf93047198b3ff63f02d0 and indeed was included in 4.0.0 onwards.
This probably needs to be fixed at aiohttp_apispec side. Opened an issue there. https://github.com/maximdanilchenko/aiohttp-apispec/issues/105
aiohttp_apispec requirements.txt forbids using apispec 4+ and is not officially ready for it. As it seems, this bug was made possible by Arch Linux package https://www.archlinux.org/packages/community/any/python-aiohttp-apispec/ not having upper version bounds on dependencies (which bounds are discouraged on a rolling release system) Notified package maintainer.
pip install --user aiohttp_apispec
(or using a virtual environment) seems to fix the problem at least temporarily.
Thanks for both reporting and diving into this issue. This would've been a pain to debug on our side as none of our core developers really use Arch on a daily basis.
We'll keep an eye out on the upstream issues. Please let us know if we can help you out in any way.
If we explicitly add apispec>=3.2.4, <4.0
to requirements.txt
, should it solve the problem on Arch Linux until the Arch Linux package is fixed?
I don't think it will make a difference.
If installing aiohttp_apispec
via pip
, apispec 4 is already forbidden, so a lower version will be selected.
If installing via pacman, deps and conflicts will be checked as per PKGBUILDs and ignore requirements.txt
On the plus side, aiohttp_apispec
is fairly small, so once @maximdanilchenko or another upstream maintainer is back the apispec 4 compatibility might happen fast.
If a new aiohttp_apispec
release is made upstream, propagating an update to Arch packages is usually fast.
Also, if someone makes a quick fix to aiohttp_apispec
, it technically can be applied to the Arch package right away even before upstream reacts to a PR.
Sentry issue: TRIBLER-2V
https://github.com/maximdanilchenko/aiohttp-apispec/issues/105 has been closed by https://github.com/maximdanilchenko/aiohttp-apispec/pull/115, this bug can probably be closed as well
Great to hear that!
Please, fill all relevant items:
[x] I have read CONTRIBUTING.rst
[ ] I have tried with the latest pre-release version and I still can reproduce the issue. (release-7.6 is branch is ahead of devel branch, is it relevant?)
Tribler version/branch+revision:
branch: release-7.6 commit: 0c841fdf36e5497231f6f79d5451e74163a48ac3
Operating system and version:
Arch Linux, 5.9.11 kernel (aiohttp 3.7.3 aiohttp-apispec 2.2.1 apispec 4.0.0)
Steps to reproduce the behavior:
git checkout release-7.6
git submodule update --init
cd tribler/src
/tribler.sh
Expected behavior:
Tribler starts
Actual behavior:
Crash before booting up
Relevant log file output: