From fb14c4fd1a4ac9f27c6ae2f66197a324ae2ee6ad Mon Sep 17 00:00:00 2001 From: Artur Shiriev Date: Sat, 17 Oct 2026 20:25:06 +0300 Subject: [PATCH] docs: say Celery tasks resolve from their own app's container --- docs/integrations/celery.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/integrations/celery.md b/docs/integrations/celery.md index c82c0910..c4e1d6b3 100644 --- a/docs/integrations/celery.md +++ b/docs/integrations/celery.md @@ -66,8 +66,9 @@ def run_report(report: typing.Annotated[Report, FromDI(Report)]) -> str: `setup_di(app, container)` registers the container for the app and connects Celery's worker signals that open and close it. `@inject` builds a `Scope.REQUEST` child container for each task call and resolves `FromDI`-annotated parameters from it. It looks the -container up through Celery's `current_app` at call time, so it resolves against -whichever app is active. +container up through the running task's app, so a task resolves from its own app's +container even when another app is current. Outside a task it falls back to Celery's +`current_app`. Before modern-di-celery 4.2.2, the lookup always went through `current_app`. Celery closes containers with `close_sync()`, both the per-task child and the root at worker shutdown. Finalizers must therefore be sync: an async finalizer makes the close