Which component is this bug for?

Traceloop SDK

📜 Description

v0.39.4 of traceloop-sdk (specifically #2867) locked down the typing for the @task and @workflow decorators via the use of ParamSpec. Unfortunately, this seems to be causing issues with Pyright's type checking, specifically when the wrapped function has arguments.

The following is encountered through simple use of either decorator when the instrumented function has arguments (where "[...]" is the signature of the function):

 Type "[...]" is not assignable to type "(**P) -> (R | Awaitable[R])"

I've confirmed that this issue goes away when downgrading traceloop-sdk to v0.39.3.

👟 Reproduction steps

1. Create a fresh Python project with the following requirements:

traceloop-sdk==0.40.2
pyright==1.1.400

2. Create a Python file (main.py) with the following:

from traceloop.sdk.decorators import task, workflow

@task(name="add")
def add(a: int, b: int) -> int:
    return a + b

@workflow(name="add_five")
def add_five(n: int) -> int:
    return add(n, 5)

3. Run the Pyright CLI:

pyright

👍 Expected behavior

The following output from pyright:

0 errors, 0 warnings, 0 informations

👎 Actual Behavior with Screenshots

The following output from pyright:

main.py
  main.py:3:2 - error: Argument of type "(n: int) -> int" cannot be assigned to parameter of type "F@workflow"
    Type "(n: int) -> int" is not assignable to type "(**P) -> (R | Awaitable[R])"
      Type "(n: int) -> int" is not assignable to type "(**P) -> (R | Awaitable[R])" (reportArgumentType)
  main.py:7:2 - error: Argument of type "(a: int, b: int) -> int" cannot be assigned to parameter of type "F@task"
    Type "(a: int, b: int) -> int" is not assignable to type "(**P) -> (R | Awaitable[R])"
      Type "(a: int, b: int) -> int" is not assignable to type "(**P) -> (R | Awaitable[R])" (reportArgumentType)
2 errors, 0 warnings, 0 informations

🤖 Python Version

Python 3.13.2

📃 Provide any additional context for the Bug.

Dependencies: traceloop-sdk==0.40.2, pyright==1.1.400

w.r.t. fixing for Pyright users – I haven't stumbled upon a definitive answer, but it seems as though a fallback overload for both task/workflow with looser typing may be required. I was unable to get a fix working locally through fiddling with the typing – happy to submit a PR if there's a clear path to addressing this with no impact on users of other type checking systems (i.e. Mypy), though.

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find similar issue

Are you willing to submit PR?

Yes I am willing to submit a PR!