Repository navigation
fix: pyoaev crashes on Python 3.14: 'object has no attribute __annotations__' in RESTObject._create_managers #346
Description
Summary
pyoaev crashes at startup on Python 3.14. Any collector/injector that
instantiates a RESTObject (e.g. collector.create() during setup) raises:
AttributeError: 'Collector' object has no attribute '__annotations__'. Did you mean: '__annotate_func__'?
This makes the current OpenAEV-Platform/collectors images (whose Dockerfile was
bumped to python:3.14-alpine) fail to start entirely.
Stack trace
File ".../pyoaev/daemons/collector_daemon.py", line 90, in _setup
self.api.collector.create(config, collector_icon)
File ".../pyoaev/mixins.py", line 218, in create
return self._obj_cls(self, server_data)
File ".../pyoaev/base.py", line 54, in __init__
self._create_managers()
File ".../pyoaev/base.py", line 160, in _create_managers
for attr, annotation in sorted(self.__annotations__.items()):
File ".../pyoaev/base.py", line 90, in __getattr__
raise AttributeError(message)
AttributeError: 'Collector' object has no attribute '__annotations__'
Root cause
RESTObject._create_managers() reads self.__annotations__ directly. Under
Python 3.14 (PEP 649 / PEP 749, deferred annotations), __annotations__ is no
longer guaranteed to be a plain attribute resolvable this way — and RESTObject
also overrides __getattr__, so the missing attribute raises instead of
returning an empty dict.
Suggested fix
Use inspect.get_annotations() (or walk the MRO collecting
cls.__dict__.get("__annotations__", {})) instead of self.__annotations__:
import inspect
annotations = {}
for klass in type(self).__mro__:
annotations.update(inspect.get_annotations(klass))
for attr, annotation in sorted(annotations.items()):
...Impact / context
Found while testing OpenAEV-Platform/collectors#590 (Splunk ES collector fix).
The collector image built on 3.14 does not start; I validated that PR on a 3.13
build. Until this is fixed in pyoaev, collector Dockerfiles should stay on 3.13.
Environment
- Python 3.14 (python:3.14-alpine)
- pyoaev from OpenAEV-Platform/client-python (current main)
Activity
[-]pyoaev crashes on Python 3.14: 'object has no attribute __annotations__' in RESTObject._create_managers[/-][+]fix: pyoaev crashes on Python 3.14: 'object has no attribute __annotations__' in RESTObject._create_managers[/+]Megafredo commentedon Sep 17, 2026
Hey Sébastien MIGUEL (@Seb-MIGUEL), thanks for reporting this !
However, I believe the issue has already been fixed on the
client-pythonside. The change was made last week in this commit 128029a, specifically to correctly handle annotations in light of the changes introduced in Python 3.14.Issue reference: #337
The chosen solution relies on
typing.get_type_hints(), which is also the recommended approach in the Python documentation for resolving type annotations: https://docs.python.org/3/library/typing.html#typing.get_type_hints .Consequently, it seems to me that the behavior described in the issue corresponds to a version of
client-pythonthat does not yet include this fix. Could you check if the version of the client-python being used is up to date?For reference, this fix was specifically related to standardizing the collectors in this PR: OpenAEV-Platform/collectors#562
Seb-MIGUEL commentedon Sep 17, 2026
Thanks Frédéric BASLER (@Megafredo), you're right that the code fix landed on
mainwith 128029a (#337), and I confirm it works: I reproduced on Python 3.14.7 withpyoaev==3.260904.0(crash, same stack trace as above) and withpyoaev==3.260917.1(OK). So on the client-python side this is a duplicate of #337 and can be closed.The gap is on the release / pin side, which is why the collector images fail:
3.260904.0, tagged Sept 4, i.e. before the fix (the tag is one commit behind 128029a). The first release containing the fix is3.260917.0, published this morning.main(including today's3.260917.1release commit), every collector'spyproject.tomlstill pinspyoaev = "3.260904.0"(netwitness even3.260805.0), while the Dockerfiles usepython:3.14-alpineandrequires-python = ">=3.14". A defaultdocker buildtherefore installs the broken version on 3.14 and the container crashes at startup.mainas a path dependency, so tests run against the fixed code. That explains why the tests are green while the images are not.--build-arg PYOAEV_GIT_BRANCH_OVERRIDE=mainonmain, but the Dockerfiles declareARG PYOAEV_GIT_REF_OVERRIDE. The names don't match, so the override is a no-op and even themainimages are built with the PyPI pin.Proposed follow-up on the collectors repo (happy to open the PR):
pyoaevto3.260917.1in all collectors'pyproject.toml.ARG(or vice versa).Fine with me to close this one as a duplicate of #337 once the collectors follow-up is tracked.
Megafredo commentedon Sep 17, 2026
Thanks Sébastien MIGUEL (@Seb-MIGUEL) !
Yes, you're absolutely right! Thanks for the details, and good catch regarding the environment variable and the
pyproject.tomlfiles! <3We'll fix the issues. It would be great if you could create the corresponding issues. We'll handle the fixes as soon as possible!
Thanks again for reporting this and for the verification!
guzmud commentedon Sep 18, 2026
Closed and replaced with the more specific issues: