fix(Ray): Retain the original function name when patching Ray tasks

[svartalf]

Description

Without "@functools.wraps" added, Ray exposes Prometheus metrics with all tasks named "new_func"

Issues

• Follow up to !4430 comments

Reminders

• Please add tests to validate your changes, and lint your code using tox -e linters.
• Add GH Issue ID & Linear ID (if applicable)
• PR title should use conventional commit style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community

[cursor]

Bug: Tracing Parameter Patching Causes Signature Errors

The _tracing parameter patching logic unconditionally appends the parameter, which can lead to two issues: a ValueError if user_f already defines _tracing, or an invalid signature if **kwargs is present, as keyword-only parameters must precede **kwargs.

 

[seer-by-sentry]

Potential bug: Adding the _tracing parameter without checking for its existence can cause a ValueError if the user's function already has a parameter with that name, crashing the application.

• Description: The Ray integration modifies the signature of a user's function to add a _tracing parameter. However, it does not first check if a parameter with that name already exists. If a user decorates a function that already has a _tracing parameter, the code attempts to add a duplicate. This will cause inspect.signature.replace() to raise a ValueError because duplicate parameter names are not allowed. This error is unhandled and will crash the application when the function is decorated, preventing the application from starting.

• Suggested fix: Before appending the _tracing parameter to the params list, iterate through the existing parameters to check if one with the name _tracing already exists. If it does, do not append the new parameter.
  _{severity: 0.7, confidence: 0.95}

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[svartalf]

Follow-up to the CI run:

• mypy failure can be solved by adding # type: ignore[attr-defined]. I'm postponing adding a commit with it in case if we would want to include anything else after the discussion
• Not sure what to do with LLM suggestions, as introducing a "hidden" parameter for tracing propagation seems to be the way to do things?

[sentrivana]

Hey @svartalf, thanks for the PR! TL;DR, it all looks good to me, but see below for a couple of optional suggestions.

Re: LLM suggestions, we could rename the arg to _sentry_tracing or something less generic to reduce the likelihood of collisions. FWIW I don't think it's necessary, so feel free to ignore.

If you can add a test or integrate a check for this into one of the tests in the existing test suite, that'd be awesome.

Approving already though since it looks good to me as is, pending the type: ignore.