What happened?
crossplane.function.runtime.serve() calls asyncio.get_event_loop() from a
synchronous context:
https://github.com/crossplane/function-sdk-python/blob/main/crossplane/function/runtime.py#L98
On Python 3.14 that raises instead of creating a loop, so any function built on
the SDK dies at startup:
Traceback (most recent call last):
File "/app/.venv/bin/my-function", line 10, in <module>
sys.exit(main())
File "/app/function/main.py", line 42, in main
runtime.serve(
...
File "/app/.venv/lib/python3.14/site-packages/crossplane/function/runtime.py", line 98, in serve
loop = asyncio.get_event_loop()
File "/usr/local/lib/python3.14/asyncio/events.py", line 718, in get_event_loop
raise RuntimeError('There is no current event loop in thread %r.'
% threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'MainThread'.
get_event_loop() creating a loop when none is running was deprecated in 3.12
and removed in 3.14; the call now only succeeds from inside a running loop.
How can we reproduce it?
Scaffold from function-template-python, set the base image to
python:3.14-slim, build, and run the entrypoint — the process exits
immediately with the traceback above. Nothing else is needed; it fails before
any request is served.
What is the SDK version?
crossplane-function-sdk-python 0.14.0 (current release), and main at the
time of writing still has the same call.
Why this may have gone unnoticed
pyproject.toml declares requires-python = ">=3.11", but CI pins a single
version — PYTHON_VERSION: '3.11' in .github/workflows/ci.yml — so nothing
exercises the upper end of that range. 3.13 still accepts the call (deprecated
only), which is why this surfaces first on 3.14.
Additional context
Found while testing a Python 3.12 → 3.14 bump on a function of ours. Worth
flagging how quiet the failure is: on 3.14 the image builds, every dependency
imports, and the full unit suite passes. Only starting the entrypoint fails, so
the bump looks green everywhere except in a cluster, where it crash-loops.
Happy to test a patch against a real function if that helps — not opening a PR
myself, since serve() also installs signal handlers and calls
run_until_complete on that loop, and how you want it restructured (own loop
via new_event_loop, or moving to asyncio.run) is a design call for you.
What happened?
crossplane.function.runtime.serve()callsasyncio.get_event_loop()from asynchronous context:
https://github.com/crossplane/function-sdk-python/blob/main/crossplane/function/runtime.py#L98
On Python 3.14 that raises instead of creating a loop, so any function built on
the SDK dies at startup:
get_event_loop()creating a loop when none is running was deprecated in 3.12and removed in 3.14; the call now only succeeds from inside a running loop.
How can we reproduce it?
Scaffold from
function-template-python, set the base image topython:3.14-slim, build, and run the entrypoint — the process exitsimmediately with the traceback above. Nothing else is needed; it fails before
any request is served.
What is the SDK version?
crossplane-function-sdk-python0.14.0 (current release), andmainat thetime of writing still has the same call.
Why this may have gone unnoticed
pyproject.tomldeclaresrequires-python = ">=3.11", but CI pins a singleversion —
PYTHON_VERSION: '3.11'in.github/workflows/ci.yml— so nothingexercises the upper end of that range. 3.13 still accepts the call (deprecated
only), which is why this surfaces first on 3.14.
Additional context
Found while testing a Python 3.12 → 3.14 bump on a function of ours. Worth
flagging how quiet the failure is: on 3.14 the image builds, every dependency
imports, and the full unit suite passes. Only starting the entrypoint fails, so
the bump looks green everywhere except in a cluster, where it crash-loops.
Happy to test a patch against a real function if that helps — not opening a PR
myself, since
serve()also installs signal handlers and callsrun_until_completeon that loop, and how you want it restructured (own loopvia
new_event_loop, or moving toasyncio.run) is a design call for you.