How to use fastapi dependencies in taskiq tasks (or what I am missing)

[devraj]

We use fastapi and it's dependency feature extensive, our most frequently use is get_async_session to get a SQLAlchemy session to our postgres databases, which looks like:

async def get_async_session() -> AsyncSession:
    async_session = sessionmaker(
        engine, class_=AsyncSession, expire_on_commit=False
    )
    async with async_session() as session:
        yield session

and each fastapi route is able to inject this like:

@router.post(
    "/signup",
    status_code=status.HTTP_201_CREATED,
)
async def signup_user(
    request: SignupRequest,
    session: AsyncSession = Depends(get_async_session)
) -> SignupResponse:

    # Try and get a user by email
    user = await User.get_by_email(session, request.email)
    if user:
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail="User already exists"
        )

    user = await User.create(session, **request.dict())

Since taskiq has a similar ideas, I went onto read if I could use fastapi dependencies in taskiq only to find this cool warning and the a link taskiq-dependencies. I am now following the docs there to achieve the above.

My taskiq task looks like (for debugging):

from sqlalchemy.ext.asyncio import AsyncSession
from taskiq_dependencies import Depends

@broker.task
async def send_account_verification_email(
    user_id: str,
    session: AsyncSession = Depends(get_async_session)
) -> None:

    user = await User.get(session, user_id)

    import logging
    logging.error("===================")
    logging.error(session)
    logging.error(user_id)
    logging.error(user)
    logging.error("===================")

which tells me that session is of type taskiq_dependencies.dependency.Dependency which I would expect to be an object of AsyncSession:

h.tasks:send_account_verification_email with ID: 0ec8f489678f4192a2b065e1ab3158fe
harvest-api            | 2023-08-12 05:25:29,764 INFO sqlalchemy.engine.Engine ROLLBACK
harvest-worker         | [2023-08-12 05:25:29,764][root][ERROR  ][worker-0] ===================
harvest-worker         | [2023-08-12 05:25:29,764][root][ERROR  ][worker-0] <taskiq_dependencies.dependency.Dependency object at 0xffff8acbda90>
harvest-worker         | [2023-08-12 05:25:29,764][root][ERROR  ][worker-0] 7303192a-bed5-4a28-8f18-2cc7a370d25f
harvest-worker         | [2023-08-12 05:25:29,764][root][ERROR  ][worker-0] None
harvest-worker         | [2023-08-12 05:25:29,764][root][ERROR  ][worker-0] ===================

I am wondering if anyone can throw some light on what I might have missed in using taskiq_dependencies to use fastapi dependencies in my taskiq tasks. Thank you.

I also discovered that UUID is not serialisable (not sure why) if that's what I pass as a parameter to the task.

[s3rius]

I guess, that problem is because now tasks resolved after startup.
Before the release https://github.com/taskiq-python/taskiq-fastapi/releases/tag/0.3.0 taskiq-fastapi was resolving all tasks, used by an application before startup. Now it does it during the startup. Because this behavior was causing bugs, when application uses multiple brokers.

Since taskiq calculates all dependency graphs on startup, we need to know about all tasks before the startup event. To solve your problem, you can either use --fs-discover parameter, or add modules with your tasks directly to worker command.

taskiq worker app.tkq:broker app.tasks

Or

taskiq worker app.tkq:broker --fs-discover

All tasks imported like this become available to broker before startup events and it will calculate all dependency graphs for it.

You can get more information about how to automatic task importing here: https://taskiq-python.github.io/guide/cli.html#auto-importing.

[s3rius]

Actually, now I'm thinking that maybe calcualting dependency graphs in runtime is an okay thing to do. Just to make taskiq more intuitive.

[s3rius]

And, finally. Actually, now taskiq-dependencies compatible with Depends from fastapi. We made it to make taskiq-fastapi package possible.

[devraj]

--fs-discover did the trick, thank so much for responding @s3rius