feat: add `SentryIsolationScope` decorator

[feelgood1987]

Problem Statement

Add a new decorator, SentryIsolationScope, to create and apply an isolation scope to the relevant method.
Similar to the SentryCron or SentryTrace decorators, this would be useful in situations where we don't have HTTP requests but still need an isolation scope.
For instance, in our case, some MQ event consumers subscribe to a message broker like RabbitMQ. In such cases, there are no HTTP requests, so every Sentry.getIsolationScope call targets the global scope.
Having a decorator to create and assign an isolation scope to these functions would be a great feature for such use cases.

Solution Brainstorm

I've looked for a similar feature but unfortunately couldn't find any, so I've created this issue

[chargome]

@feelgood1987 thanks for the suggestion. You could make use of withScope or withIsolationScope wherever you need it – is there an advantage of putting that into a separate decorator for you?

[feelgood1987]

@feelgood1987 thanks for the suggestion. You could make use of withScope or withIsolationScope wherever you need it – is there an advantage of putting that into a separate decorator for you?

Will those methods work with non-HTTP requests, actually the service is a message-broker subscriber, and since I could understand from the documentation, that those methods, create scope based on an HTTP request, in our case, there be no HTTP request, will withIsolationScope work for this sort of issues?

The reason, we've suggested having this new decorator, is the similar nature of the issue to something like SentryCron

[chargome]

Yeah this should not be http related. As for the decorator I would not see any benefit from it as it would not abstract any logic from the original withScope or withIsolationScope methods – so I would lean towards not implementing it tbh.

[feelgood1987]

Yeah this should not be http related. As for the decorator, I would not see any benefit from it as it would not abstract any logic from the original withScope or withIsolationScope methods – so I would lean towards not implementing it tbh.

As you've described, using withScope or withIsolationScope will definitely work for us. Thank you for your help!
However, we could consider the following benefits of having a dedicated decorator:

• Eliminating Redundant Code:
  • A decorator would prevent the need for extra code in non-HTTP functions where we have to manually initialize the scope each time.
• Reducing Developer Confusion:
  • For HTTP requests, we typically rely on getIsolationScope by default. However, for non-HTTP scenarios, it might not be immediately clear to developers whether they need to create a new scope or not. A decorator would simplify this by standardizing scope creation, making it more intuitive.